Life, in its essence, is a quest for satisfaction, but what is it that satisfies, what works and what doesn’t when it comes to R&D?
Life, in its essence, is a quest for satisfaction, but what is it that satisfies, what works and what doesn’t when it comes to System R&D?
Eight years ago, in High School, I began building a fairly complex system. At that time, I was a teenager with no background in project management nor agile techniques. Yet, four years after starting, my little creature landed me at INFN and CERN.
What was it that worked? Was it a concept so obvious it had no possible blunders into it? Quite far from that. What made the wheel spin in the end, was burning a hefty amount of self-built electronic board.
Trial and error to its essence.
After landing at INFN, I started another project. But this time, I had a fundamental help: I had a mentor, an agile coach.
The time it took to reach a final product reduced to half of what it took in high school. Four years to two to go from a draft on paper to something that worked.
The difference? Instead of burning and randomly trying different options, I began to focus on incremental improvements.
First, we created the core of the product, then, by asking every week and then feedback to different people, we changed things, little by little, focusing on a few details at a time.
The result was six main product iterations with many incremental ones. But the remarkably important part was that by building them based on feedback from different users, we gained a deep insight into what people expected. What was it they wanted to be satisfied, and what were their expectations. More importantly, we also understood what created those requests.
All of this would not have been possible without continuously iterating and seeking opinions.
What worked, and what I believe works in a heterogeneous system R&D, is not to have a big plan with a carefully designed Gaant chart.
A broader vision of the bigger picture is needed. Don’t get me wrong. But when you have it, what works is to focus on a few little things at a time, starting from the core and going out, prototype them, and then ask for opinions.
What works then, is to put those little things together, two at a time, and then ask for even more opinions to different people, the ones that are going to use the system.
In the end, without seeking novelty and getting stuff wrong, without a sharp contrast, none of us would have the certainty of being on the right path.
The takeaway?
Find the core of your system, discover the reason why people should use it. Then work on it, one step at a time, and seek feedback from someone (not you or people too close to you) who is possibly going to use it. And again with all the other parts which are not so close to the core.
Then?
Repeat.
Nadim Conti 