Industrial Strength Innovation Project Management

H. Dominic Covvey, National Institutes of Health Informatics

IS IPMSome time ago I wrote an article that addressed the management of innovation. I thought I would revisit a number of key points and add several along the way.

I’ll start this article the same way, by indicating my respect for the work of the Project Management Institute (PMI) in promoting the professionalism of project management (PM). Becoming PMI-certified is definitely a worthwhile effort.

Innovation Projects

However, much of what I have learned about PM from sources like PMI seems to focus on what I’ll call ‘Classic Project Management’, where the description of the work to be done is like a recipe for a cake or the plan for a standard building or vehicle. What about the situation where a project involves substantial innovation? This might be a project where important unaddressed issues are there at its initiation, where the project maybe exists in a changing or somewhat unstable context, and/or where the challenge the project is targeting hasn’t been faced before, and/or where the methodology for proceeding is still an open issue? I called projects like this ‘Innovation Projects’ or IP, which, not accidentally, has the same acronym as ‘Intellectual Property’…these projects often evolve such.

Innovation Projects can’t be fully specified at the start and experimentation, discovery, alternate solution evaluation, usability assessment, and negotiation are necessary project activities. In my previous article I used Patient Portal development as an example, and this one still holds. However, there are many other types of project that should have the IP designation. A research project, of course, is an IP. Rationalization or re-engineering of a complex organization is another…and projects to put almost any tool in the hands of a patient are IPs. In fact, I could assert that many of the things that we claim are ‘cut-and-dried’ simply are not…it’s just that we think or hope they are. Almost any large-scale system development is actually an IP, and the largest should be called and I2P (‘Intense Innovation Project’…or you might prefer: ‘Industrial-strength Innovation Project’) and these very often fail, data warehouses being particularly mortal examples.

Characteristics of Innovation Projects

Innovation Projects have a number of characteristics:

  • An IP is a departure from what’s gone before; it is new or major components are new…that is intrinsic to any innovation.
  • Despite other characteristics that may make it difficult, there must be a well-articulated purpose, understood and embraced by all participants, to which the project is dedicated.
  • Not everything is known about precisely what the product(s) of the IP will look like.
  • The ways of proceeding (methods, actions) may not be fully decided.
  • The schedule may have milestones, but having checkpoints for schedule modification is usual.
  • Most IPs have an array of collaborators who bring the necessary spectrum of competencies to the table.
  • There is a need for creative co-thinking among the participants and negotiation about how to proceed or to redirect actions previous agreed to.
  • It can be guaranteed that things will change substantially within the duration of the project, particularly related to tools and methods, but sometimes related to alterations in scope, timing and budget…although there are limits to each of these.
  • There, almost certainly, will need to be parallel approaches to very challenging aspects of the project and the need for inter-approach competition and selection of a ‘best approach’ at some point.
  • It is absolutely crucial that assessment/evaluation of the processes and interim products (like prototypes) be built into the IP: designed into the project from the start, included in its execution, used to determine if the project is actually on course, and used as the basis for redirecting efforts.

Innovation to the Nth Power

I’m a student of the Manhattan Project, the program to develop the nuclear fission weapon during World War II and the breeding ground for the ideas that resulted in the fusion (thermonuclear) weapon. There are many excellent books (2, 3) on this topic that are fascinating and that reveal the key characteristics of real innovation. I’ll just touch on this briefly here.

Now, none of us will probably ever participate in anything like this, but our national eHealth/EHR effort does have some of its characteristics (one of which, I hope, is not an explosion!). However, the Manhattan Project does have some parallels from which we can learn.

First of all, physicists knew most of the basics of nuclear fission – but not all the details – for years before the project began – just like we often know (or believe we do) many of the basics of our eHealth projects…but not all the details.

Next, the Manhattan Project knew about the components required (e.g., the ‘active material’, Uranium 235 (U235) and Plutonium 239 (Pu239), ‘tampers’ – to contain the reaction, ‘initiators’ to kick start the reaction, chemical explosives to drive the active materials into a ‘critical mass’ that would explode, etc.), but they did not know how to assemble everything to get an effective weapon. That should sound familiar when the words software and interfaces (eHealth’s active materials), hardware, networks, people, etc. are substituted in drawing parallels to eHealth.

In order to figure out how to assemble the components, there were many experiments (in parallel), and, to get the active materials, there were a number of types of production facilities created in parallel (for Uranium 235: gaseous diffusion, electromagnetic separation, centrifuge and other massive plants), again in parallel and these were allowed to compete, the best ones were selected at each stage of the program, and eventually many were obsoleted, with centrifuges being the dominant technology for producing Uranium 235 today. And, there was a completely separate stream for producing and separating Plutonium.

At just about every step along the way there were surprises. It turned out that Plutonium required an implosion approach, while making Uranium 235 go bang was far easier. Early nuclear reactors had problems. Early designs didn’t work and major discoveries were made like that one could compress metals into critical densities with chemical explosives (in the fission weapon) and even with radiation (in the fusion weapon).

Dr. Robert Oppenheimer was responsible for bringing all the physics – and keeping the gaggle of virtually unmanageable physicists (including quite a few Nobel Laureates) – together, but Gen. Leslie Groves was really the project manager, and was responsible for turning all that physics into a deliverable weapon. Oppenheimer was highly respected by the scientists, even the Nobel Laureates, even though he hadn’t been so honored. And Groves was respected by the military – even beyond the prerogatives of his rank.

The whole thing is quoted as costing about US$2B in 1943 dollars or about US$260B in 2010 dollars. Interestingly, this is what some estimate getting an adequate level of eHealth in the U.S. will cost. The project took between 3 and 4 years according to when you set the real start date.

What Does This Tell Us about Innovation Projects?

If we look back given what we know today, the Manhattan Project had a number of ways of dealing with innovation that may be lessons we yet need to learn:

  1. It was a war-time project to scoop the enemy (Germany, particularly, was pursuing or believed to be pursuing, the development of nuclear weapons) and also to end the war. Because of this, the budget was effectively unlimited. However, Groves – the project manager – had a fantastic reputation for squeezing the maximum out of resources and getting to the outcome (he managed the building of the Pentagon) and therefore he was deemed worthy of trust and was TRUSTED with the blank cheque!
  2. There were effectively 2 coordinated streams and management hierarchies: the scientists in one branch and the military in the other. But they both worked towards the same purpose, both were very well managed and they were required to collaborate productively. This allowed each to have its own ‘respect and authority hierarchy’, but to work together. Scientists didn’t get subjugated to the military (or the project manager) and the military didn’t get driven nuts by the scientists.
  3. The participants used what today we call agile development: there was a starting set of high-level requirements, some initial design ideas, a number of development tools (e.g., the U235 and Pu239 production processes), and many testing methods (read about ‘tickling the tail of the dragon’ if you have time…it’ll scare you!). All of this was iteratively refined and improved and the key deliverables were addressed even though there were many loose ends.
  4. The project leader had the psycho-social persona that enabled him to deal with the very strange environment, a chief scientist who had a number of significant problems and a questionable background (he was involved with communists earlier in his career), a mix of elite and aloof scientists, some completely unmanageable individuals (like Edward Teller whom Groves left to Oppenheimer), and a whole other culture – the military one – that could easily clash with the scientists. That’s almost as tough as getting administrators and physicians in the same room….
  5. The entire program was successful, despite being among the largest scale enterprises ever undertaken by human beings.
  6. The program was also challenged to operate under deep secrecy. When Harry Truman became President, he learned about the Manhattan Project for the first time and he had been the Vice President during the project. We think it’s hard being constrained by privacy legislation!
  7. What is interesting is that it used some of the methods that I cited in my earlier article, a touch of “Chaordic Management” (4) that enables innovation while at least avoiding the worst aspects of strictly command-and-control approaches that never would have worked for the scientists.
  8. …And all of the players were competent in their own fields and highly secure.

Conclusions

Innovation Projects are different sorts of beasts. They are often more complex than classic projects, they need more flexible tools and approaches, and they likely need a different genre of leadership(4) if they are to run smoothly and be successful.

Especially when these projects are medium to large scale, they must engage significant teams of academics, developers, care providers, administrators and managers in a hard-to-manage, often deep, collaboration. To enable a reasonable likelihood of harmonious group work, especially talented and well trained project leaders are needed who profoundly understand the challenge, the project’s techniques and tools, the inter-dependence of the team members, the need for robust inter-communication among all the players and stakeholders, agile methods, a built in project performance assessment system, and who have an amazing finesse in people management. This will likely only be possible for mature and highly trained professionals with many years of experience and great personal security.

Unless these needs are recognized, our efforts will often “bomb”.

References

  1. H. D. Covvey, “Managing Innovation”, Healthcare Information Management and Communications Canada, February 2008, Pages: 42-43.
  2. R. Rhodes, The Making of the Atomic Bomb, Touchstone, 1986.
  3. J. Baggott, Atomic: The First War of Physics and the Secret History of the Atom Bomb, Icon Books, 2009.
  4. D. Hock, The Birth of the Chaordic Organization, Bantam Doubleday Dell Publishing Group, ISBN: 0385482191, 1999

Dominic Covvey (FACMI, FHIMSS, FCIPS, SMIEEE, ITCP) is an Adjunct Professor at the University of Waterloo and the University of Ontario Institute of Technology. He is also the President and Director of the National Institutes of Health Informatics. He was the Founding Director of the Waterloo Institute for Health Informatics Research at the University of Waterloo (2003-2010). His research is in the representation and analysis of healthcare workflow, the definition of competencies and curricula in Health Informatics and the design of the Electronic Health Record.

Advertisements
Tagged with: , , , , ,
Posted in Dominic Covvey
%d bloggers like this: