Project management–the activity of creating a plan for a project, complete with timelines displayed in fancy Gantt Charts, risk matrices, status reports, and the kind of regular team meetings that give meetings a bad name (and being a slave to a rigid, excessively complicated process)– doesn’t mix with innovation development. Developing an idea on paper into something real is the textbook definition of “working in the dark.” Outcomes are uncertain. It’s easy for an idea on paper to look and sound divine, until reality sets in and quickly makes you feel mortal. To borrow from a cliché: you just don’t know what you don’t know.
Working in the dark can create a violent collision when project management with a slavish adherence to process tries to rein in an innovation project. That’s not to say there’s no need for structure to development; there are certainly logical steps that need to be taken. I am a big proponent of project milestones.
But it can go too far.
One company I worked for was notorious for torture by project management. They absolutely fetishized process. (I think their unofficial motto was, “Why make life simple when you can make it complicated?”) I was a member of project teams building and testing new devices–sometimes VERY new and unusual devices, meaning we didn’t know whether the device did anything useful. We had to do the testing and we understood that would likely mean we would need to do it iteratively. This is normal.
However, this company’s DNA compelled them to make us spend a couple of months creating a detailed project charter with: timelines at one-week resolution, all necessary tasks, all personnel involved listed by name, 3X3 risk matrix identifying the likelihood that risk will not happen (this is not a typo, it’s how the risk assessment exercise was worded) from kickoff to project launch (!!!). Oh, and every part of the plan had to adhere to the company’s Innovation-to-Market process, which was contained in a spiral-bound, full color book; there were coworkers who referred to themselves as “students” of this process. Yikes! This is not going to end well!
Never mind that this process was originally designed for superficial changes to mature products, not novel technologies. We had to adhere to that charter while working in the dark–and we didn’t even know if the dang technology worked!
This was nothing short of nuts. But our VPs insisted. Firm process and detailed plans were king to these project management Nazis. But for early-stage innovation?! What a bunch of BS! We never launched anything innovative using this process. It simply managed to keep a lot of people busy creating spreadsheets and other documents, and packing conference rooms with meetings.
There was one project to develop a new oral hygiene device that we really didn’t know whether or not would work. But we couldn’t start the project until the charter was created and ratified. Middle East peace treaties were less contentious and easier to agree on than these charters, but equally likely to fall apart right after ratifying. And that is exactly what happened, repeatedly.
After months of developing the charter and plan, complete with a product launch target, we’re ready to do the first clinical trial with the first prototype of this device. And… it doesn’t work… as expected. Duh! Surprise! Welcome to innovation! I repeat: this is normal. Early-stage failure can, and should, be built into the innovation process.
This completely foreseeable setback threw off the timeline in the charter. Management was furious and they were pounding the table demanding a recovery plan… Good grief! More plans. More negotiations. More meetings. And more signatures. Just shoot me! We actually lost four months of development time to the inane preparation of the project charter.
Incidentally, this type of reaction from management is a sure way of suppressing future efforts at real innovation. Who would want to stick their necks out on a new idea and go through the misery of preparing a charter, only to suffer the wrath of management when a plan hits a natural road bump early in development? No good ideas will go unpunished.
With the recovery plan ratified, the device didn’t work as expected in the second clinical trial, either. Shoot me again! Another recovery plan!
I will re-emphasize that this above-described “failure” is normal for early development of innovation. We did not succeed as we hoped during the first and second clinical trials, but we did not actually fail. The results taught us something each time that allowed us to improve our later experiments and ultimately make progress. This was information we couldn’t get in a planning exercise. It needed to be achieved experimentally.
As I’ve always explained about failure in innovation, it’s okay to fail as long as you learn something from it. It can be tremendously productive and useful. In fact, when built into innovation project management processes, failure will improve odds of success. The project will be more efficient, and resilient against unexpected setback (for instance, we overcame pandemic-related challenges with partners because we were all so aligned on next steps and risks at critical project phases in March, 2020). The only regret is wasting weeks in meetings planning, and more meetings about the planning meetings, and the other empty-calorie activities associated with onerous processes.
Torture by project management lived on at that company but, fortunately, the draconian charter approach was eventually ditched, and we were freed up to actually do some development work. A year after we abandoned project charters, we reviewed the project with our (new) VPs and they were rather impressed with the progress we made in that time. More Importantly, this innovation was developed into a product and was eventually launched. It has now been in stores for years. Every time I see it on display in the oral care aisle at Target, I’m reminded of what we persevered through to develop this device.
Admittedly, the story I just told is an extreme, nightmarish example of strangling innovation with project management and process. On the other extreme, I have also worked at a company with a seemingly complete lack of structure and project management process for development of innovation. Ironically, that company did a comparatively good job at turning innovations into commercial products. However, most companies I have worked with and for have been somewhere in between these two extremes.
As you can tell, my attitude towards applying project management and process to innovation is similar to my attitude towards eating broccoli: I don’t care for it, but will eat it as long as it’s not overcooked. However, I would be a hypocrite if I didn’t learn something from my previous employers’ failures (and successes) with developing innovation. Here’s what I’ve learned and what we’ve put into practice at Xinova to deliver innovation for our customers.
There’s a difference between early innovation and all the activities (e.g., scale-up, logistics, manufacturing, etc.) that I’ll collectively call commercialization. Project management and process is best applied in commercialization where there are many, many resources to coordinate and manage. Synchronizing all of these activities is a major undertaking and requires structure and rigid process. Relatively speaking, applying the same level of project management and process to early innovation is like taking a jack hammer to a sesame seed. It’s excessive and doesn’t lead to better results.
At Xinova, our sweet spot is in doing early innovation for our customers. We offer many services related to creating, evaluating, and demonstrating innovative solutions to meet customer needs. All of these services do have structure and deadlines. Can you then say that we practice project management and apply structure and process? Sure. Of course. But we also find that every customer and every challenge we’re presented has unique needs. Our project management practices and processes are actually very simple, but effective because they are readily adaptable to the unique needs of each project. We describe how we do this for ideation and development elsewhere to help our customers quickly evaluate technologies.
The Speaking Scientist, Nick Milanovich, PhD is a rare combination of scientist, speaker, and presentations coach, with a head for marketing and sales. In addition to being Director, Innovation Services Group at Xinova, he helps other scientists and engineers communicate in a way that is meaningful to their sponsors, investors, and customers. Nick holds a PhD in biophysical chemistry and has published and presented on diverse topics such as clinical dentistry, cancer diagnostics, and quantum mechanical modeling of aerospace materials. Nick has guided countless scientists, engineers, entrepreneurs, and organizations with developing impactful presentations, investor pitches, and marketing materials in ways that resonate with their audiences. Nick has developed a reputation for exceptional results with start-ups, national and internationally recognized companies, and universities.
PO Box #30873
Seattle, WA 98113
Xinova Japan GK
Yaesu Mitsui Building 6F
2-7-2 Yaesu, Chuo-ku
Tokyo 104-0028 Japan
10th floor, Golfzone Tower
Seoul 06072, Korea
+82 2 6952 8840
Erottajankatu 5 A 4
Affiliate offices in Tel Aviv & Vienna