Implementation will concentrate on achieving the minimum viable product or product’s features (MVP) and then you will have iterations with successive small up-and-downs that in the lean start-up world are called sprints.

I would like to further expand on this model as I found it relatively adapted to illustrate to management why proof of concept team’s resources are particularly tensed on the context of partnership co-developments. (i.e.: when 2 to more corporate and/or technology transfer partners gather to execute projects)

I have reworked the curve of effort along the timeline of a collaborative proof of concept (POC) project or early stage product/service project development in partnership. (Please excuse the sketch hand-drawn and scanned…):

Timeline on the horizontal, effort to achieve activity on the vertical axis, activities step-by-steps along the route. Two curves: the effort curve similar to the IDEO one and one relatively flat one corresponding to the available resource capacity.

Inspiration: in this phase, the objective is to stimulate the group and project team with new knowledge, for instance in a consortium of partners it consist into learning about your partner challenges but also collectively receive novelty in the field of the partnership interest (game changing trends, new techs, new methods, new business approach, …).

Ideation: you will in that phase transcribe what you have learned into ideas and proposals. My experience is that this can be quite short with a lot of suggestions to capture assemble and combine.

Maturation & Sow: this is a lengthier exercise in partnering situation as you formalize here what is the common denominator between you and other partners with similar orientations but different applicative goals. At this point of time, you may start discussing IP or results and subsequent exploitation sharing, it is better that this point be addressed before the gathering of the consortium around subjects.

Objectives: From a dozen of matured suggestion you end up here prioritizing and limiting the number of use case and project you will carry out in partnership. Quite a quick phase as I reckon as very simple to prioritize depending on budget envelope and planned resources.

Kickoff: start the enthusiast phase of launching project where you experience a peak of effort for the launch from all parties.

Execution: This phase sees up and downs on activities and effort based on the rhythm imposed by your project planning and the along-the-route adjustments. Let’s assume that you project is properly framed and managed (especially as during the objective phase you have actually planned the required resources), this phase see a plateau of effort that is in-line with expectations.

Delivery: The delivery of your MVP or final product always require a significant peak of effort including what is very often forgotten by tech teams : communication. The communication effort may be huge if during the execution phase you completely overlooked that aspect. Some projects have failed because of that.

Transfer for adoption: with an initial phase of team self-content – project is done! great! we have done a good work! BUT then a new wall suddenly appears with is the transfer of what has been done to internal parties within each of the partner’s entities… this is so often forgotten although it is key to make sure you will harvest the new competencies and new approach developed within the more downstream function of organizations (engineering, industrialization, qualification etc…)

Consolidation: at this point the team may be disbanded or being disbanding and still a lot of transfer from acquired knowhow and competencies is required especially within each partner’s entities, normally we are starting the industrialization or industrial adaptation of the POC results.

This description of steps may vary from one consortium of partners to an other and certainly my representation of it is approximative and essentially based on my experience. However, I would like to come to the point of my discussion looking at the difference between the required effort curve and the actual available resource curve. I can tell that systematically the resource available effort curve is always designed to fit the project execution phase at best (when project management is experienced) but never for the various peaks before or after.

The inspiration phase is all too often completely overlooked with effort concentrating on ideation only although this is a phase that does not require much effort (people still manage to have ideas). Then lining up with common subject requires many working sessions before getting in the relative cruise control zone of project execution.

In order to guarantee that the choices of the project subjects are sustainable along all the POC development, it is definitely required that necessary effort is spent upfront in the inspiration and scope of work framing. Failing of doing that initial time & effort investment, rushing into the execution phase, may increase the degree of effort required for the adjustment peaks and make the project more uncertain at each upheaval from smooth execution.

I will not carry on my discussion, which is already quite long, with the transfer and adoption phase later down the adventure. This article was meant to highlight the red dashed areas were teams are facing significant effort requirement and cannot cope with their usual set up. Method can help indeed but above all awareness is certainly the best thing I can share here to have partnering teams better prepared.