It seems like there are some natural laws regarding R&D projects that are valid in some (your) organizations.
§ 1 Starting an R&D project
It is always easy to start a new R&D project even if the organization has implemented a rigid Gate or decision process. A little support from the top management or some words of urgency from the CEO, and you are off to a flying start.
§ 2 Reducing time to market
R&D projects don't possess a natural sense of emergency. However, this problem can be easily fixed by selling the product (to be developed) and promising quick deliveries to key customers.
§ 3 Increasing the output
By overloading the pipeline, R&D projects are forced to run faster and on meager resources – a brilliant way to increase the output.
§ 4 Time frame
Never set a time frame for an R&D project that the project can reach! If the time frame is realistic, the project members will just become lazy.
§ 5 Terminating projects
Terminating R&D projects is an unknown concept and uncharted waters. Nobody is interested in exploring those. It may end up proving that the Gate process or decision process isn't working. Which, of course, is rubbish.
§ 6 Project budget
Always slash the project budget in half – the best way to get teams to become innovative and reduce rework.
§ 7 Closing an R&D project
R&D projects can't be closed as there is always at least one extra activity that needs to be done. Instead, they should slowly peter out in the ocean of product maintenance.
§ 8 Planning
Planning is a concept invented by consultants to bill more hours. Full speed ahead is what counts. The sooner you start coding or building prototypes, the better.
§ 9 Goals
Always start with a very vague goal. It'll give room for the team to innovate and produce an outstandingly useful product, heading straight to the unicorn level.
Thank you for contributing with this law: Virpi Ruoti
§ 10 Handling contingency and risk events
Contingency planning is a waste of time. It's like paying interest on a loan you don't have or take medicine for a condition you may get. Problems should be dealt with when (if ever) they occur.
§ 11 Focus
R&D projects should avoid using or exploring new technologies. It will introduce too many uncertainties and jeopardize the budget and time schedule. The focus must be on cutting costs in already existing products.
§ 12 Customer involvement
Customers don't know what they want and have no idea of what you can create and develop. Asking, discussing, showing, or involving customers will only provide information that will completely mess up your R&D project.
§ 13 Control
Projects should be managed by strict rules and processes enforced by disciplinary actions. Sprinkle out lots of metrics and performance indicators and sniff out even the smallest deviation. This is the best way to keep any project under control.
§ 14 The final nail in the coffin
Even if the pipeline is full and all resources are used up, management's pet projects can be included as an extra challenge in already approved and ongoing projects.
Thank you for contributing with this law: Cornelius Aichele
If you by now haven't realized the irony in the laws, you are heading for a top position in some (your) organization.
Of course, these laws are complete rubbish and nothing we recommend, but at the same time so close to reality that we are sure you have been facing variants of them in your professional life.
We need your help in stopping these natural laws from becoming accepted norms. You can contribute by sharing this post.
If you want to download a pdf with all 14 laws, use the link below:
Per and Ulf
Laws of RD projects_complete
Download PDF • 822KB