Eric: Though I don’t want to take too much of your time, I would like to put forth some questions I’ve run into.
Sylvain: Please do, it’s a pleasure.
Eric: I think you are quite right in the fuzziness in the distinction between research and development. You’re 2014 paper on “Value Management for Exploration Projects” I think lays this out nicely in which you start out noting the “paradox for project management” and conclude that pursuing both research and development in concert can benefit innovation. Does this mean you reject the use of Technology Readiness Levels all-together, or just as a principle of passing through stage-gates?
Sylvian: I don’t reject TRL at all. This is a useful tool to manage innovation, as long as it is not blindly applied to all types of projects. Furthermore it can give the false impression that uncertainty is totally managed. I’m not sure that this is the case for “exploration projects”. This is the same problem for the stage-gate approach which limits have been clearly documented by Sehti & Iqbal in the Journal of Marketing.
Eric: I was pleased to find two of your papers on the usefulness of project histories. Would it be fair to summarize that such histories are useful, not in the sense that they help us make specific decisions, but that they give us a cultural disposition toward 1) embracing uncertainty; 2) regard for stakeholders; and 3) contract flexibility? (These are the opposites of the three causes of megaproject failure noted you and Loch’s 2015 article in Flyvbjerg’s book.)
Sylvian: Absolutely !! It is also useful to 1) excavate forgotten practices, typically parallel strategies ; 2) to define the “validity domain” of existing practices i.e. where do they come from and what are they useful for. This is the message of “Lost roots”.
Eric: Learning about ambidexterity and the distinction between exploration and exploitation (from Tushman & OReilly) led me to think about all the dichotomies discussed in administration: research vs. production; policy vs. administration; technical vs. interpersonal competences; phased vs. concurrent; staff vs. line; tight vs. loose coupling; adaptation vs. selection; make vs. buy; authority vs. responsibility; centralization vs. decentralization; science vs. engineering; planning vs. doing; optimizing vs. satisficing…
Sylvian: Yes. But as James March states I think this is a fundamental tension for all kinds of organization. The “natural tendency” of organization is to exploit, not to explore. This requires specific processes. However exploitation / exploration is not like innovate / not innovate. Here the fundamental contribution is Clayton Christensen “Innovator’s dilemma”. Organization are “naturally” oriented toward “sustaining innovation” (the “exploitation” side) i.e. more of the same, more performant, for existing customers. The problem is “disruptive innovations” which does not fit culture & organizational processes. Exploration projects are here. May I suggest to read this paper (2017 PMI Paper of the year award) : http://www.sylvainlenfle.com/images/Publications/LENFLE_PMJ_Finalproof_march2016%20pour%20site%20WEB.pdf
Eric: … Does the answer always lie in the middle in some fuzzy way, where particular circumstances matter a great deal but are difficult to disentangle or communicate? Does this say anything about the explicit teach-ability of project management?
Sylvian: Excellent question. Thanks for asking. No simple answer 😉 However I strongly believe that teaching, while not making you an excellent project managemer, can help to raise your “reflection in action” (D. Schön) competency. This is very important in today’s environment
Eric: In what ways do the principles for innovation management vary with scale of the enterprise, such as between startups, corporations, and governments?
Sylvian: Excellent question (2). I think there are some common principles (such as how to manage uncertainty) but, as usual, there are strong contingencies according to the context. You cannot manage Apollo and a start-up the same way. It’s just stupid.
Leave a Reply