![\"Don't](\"\/wp-content\/uploads\/2016\/05\/dont-just-fail-fast-learn-fast-720x531.jpg\")
<\/p>\nYour projects are running into problems late in the development process. They are fully staffed and some of them even look to be moving on pace through the use of daily stand-up meetings, visual management and obeya rooms and then \u2013 BAM! \u2013 a problem arises which requires significant back-tracking in the design, a resetting of market expectations or perhaps even a re-evaluation of project viability. You wonder, \u201cHow can this happen at this late stage of development?\u201d The project hit its initial milestones and the team indicated they were making progress towards your aggressive timeline. Now, you just hope the delay and cost won\u2019t be too great and are starting to get concerned about having to shut down the project. You begin to reprioritize the other projects that were counting on the resources that should have been coming off of this one. You start factoring these delays into your revenue projections for the next two years.<\/p>\n
<\/p>\n
Because innovation requires achieving something new it always involves learning. Identifying what you think you need to learn is perhaps the key to efficient planning and execution of the early phases of product development and essential to set up success throughout subsequent execution.\u00a0 Fortunately, with a little thought early on, your teams can know what most of the big issues facing them are or at least where they likely reside.\u00a0 These issues should form the focus of the early phases of development and commercialization planning where many of them are resolved, new issues are discovered and plans are put in place to mitigate any outstanding issues that may not be resolved prior to generating a plan and fully funding the development effort.<\/p>\n
Learning is most critical in this phase of a project and actually failing<\/em> should occur at this time if ever in the course of the project.<\/p><\/blockquote>\n
Learning fast requires that you fail fast in productive ways.\u00a0 Maximizing productivity in this case is optimizing the ratio of the relevance of the learning achieved to the amount of resources (time and cost) spent learning it.\u00a0 This definition weights the \u201crelevance\u201d of a potential show-stopper unknown (one in which if you get the wrong answer then you should stop) on the high end of a spectrum with one that simply optimizes the value to you or the customer (i.e. if you get the wrong answer you can provide a slightly less valuable but still viable solution) on the low end of that spectrum.\u00a0 In between are unknowns which when known will determine design architecture decisions, design interface decisions or commercialization options that could require more or less design rework if not learned early.<\/p>\n
Prioritize Efforts on the Value of the Knowledge without Fearing the Consequences of Knowing<\/h2>\n
Unfortunately, it is often the case that the team will tick off unknowns (chalk up milestone successes) by selecting those they know they can overcome first to make progress or those for which they have resources rather than those they know are most critical to determining success or failure of the project.\u00a0 John Wooden, the legendary coach, whose wise advice to his players often included life lessons beyond the court said, \u201cNever mistake activity for achievement\u201d.\u00a0 Quite often we get caught up in demonstrating progress by prioritizing activity over meaningful effort. Our natural tendency is to tackle easy things rather than hard things so that the count of milestone \u201csuccesses\u201d rises faster.\u00a0 We will keep moving on the little things while we wait for engagement from those required for the outstanding big things in an effort to keep progressing and maintain an aggressive timeline with faith or delusion that the big stuff eventually will take care of itself.\u00a0 It is also the case that a team tasked with delivering a product will subconsciously shy away from tackling the big questions that could endanger their project.\u00a0 All of these tendencies lead to effort with little real advancement \u2013 activity without achievement.<\/p>\n
Determining where time is best spent requires a team to take the time to discover what is knowable, starting with why the organization is choosing to pursue the effort (their internal value proposition) and what the customer value proposition appears to be.\u00a0 This then enables focus to discover the critical elements needed to achieve these value propositions, including how these objectives match with the capabilities of the organization.\u00a0 Business and systems thinking then goes into prioritizing the unknowns for their importance to the project and successive decisions within it.\u00a0 Guided by this assessment the team can optimize its efforts to rapidly progress towards a successful final solution or even determine that the project is not viable because of inability or organizational unwillingness to realize critical elements of the value propositions.\u00a0 They cannot fear failure at this point because failure is a success in that it will either allow the company to move resources on to more productive efforts or allow them to \u201cpivot\u201d the project as they adapt to the new knowledge gained.<\/p>\n
Determine Unknowns Critical to Success<\/h2>\n
Once the team has its bearings about what is critical to know, they should move rapidly towards getting those answers.\u00a0 Fortunately, in most cases, they don\u2019t have to build the final product to learn the unknowns most critical to success.\u00a0 For example, unknowns are often technical issues that can be explored as modular elements of the final system and do not require the whole system to discover.\u00a0 The prototypical critical unknown is the understanding of how the customer will accept and use the product.\u00a0 This is the typical learning problem that is addressed by the concepts of failing fast and use of minimum viable product (MVP) to test. The concept of the MVP is that even this knowledge can usually be acquired or approximated with something far short of the complete package and consequently at relatively low cost.<\/p>\n
This fast (early) learning is not just necessary to understand customer needs and gain confidence about how to overcome the technical design barriers but is also necessary to overcome the anticipated commercialization barriers.\u00a0 For example, manufacturing may need to fully engage early to understand and explain the requirements enabling them to customize product on the assembly line, regulatory may need to explore the requirements for a new market or product category to ensure that the design will capture these, business development may need to establish a partner to OEM the product as the only viable way to introduce it into the market.\u00a0 If these unknowns are not resolved early they can lead to costly redesign when finally understood and may even determine the non-viability of the project at a costly later stage.<\/p>\n
Management should encourage their development teams to identify these critical unknowns and then remain focused on figuring them out.\u00a0 This requires support for appropriate engagement from the non-R&D functions prior to significant design work and before project planning for the design and commercial implementation.\u00a0 The milestones of interest during reviews should be those that contribute to solidifying the probability of a project\u2019s success rather than those that can be easily hurdled on the way to piling up meaningless statistics.\u00a0 Management should stay focused on the big issues and hold their teams accountable for reporting on this without getting lost in the minutia required to bring a product to life.<\/p>\n
Help your teams not to fear failure early in the project.\u00a0 They should fail with a purpose – to learn early.\u00a0 Make your teams take the time early to know what is knowable and this will guide them to understand what they don\u2019t yet but critically need to know.\u00a0 This is the first step toward focusing on activity which will most quickly lead to achievement.\u00a0 Encourage teams to fail early so they can learn fast.<\/p>\n","protected":false},"excerpt":{"rendered":"
Your projects are running into problems late in the development process. They are fully staffed and some of them even look to be moving on pace through the use of daily stand-up meetings, visual management and obeya rooms and then \u2013 BAM! \u2013 a problem arises which requires significant back-tracking in the design, a resetting […]<\/p>\n","protected":false},"author":5,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_genesis_hide_title":false,"_genesis_hide_breadcrumbs":false,"_genesis_hide_singular_image":false,"_genesis_hide_footer_widgets":false,"_genesis_custom_body_class":"","_genesis_custom_post_class":"","_genesis_layout":"","footnotes":""},"categories":[1,7,31],"tags":[35,36,52,46],"_links":{"self":[{"href":"https:\/\/www.ioipartners.com\/wp-json\/wp\/v2\/posts\/1681"}],"collection":[{"href":"https:\/\/www.ioipartners.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.ioipartners.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.ioipartners.com\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/www.ioipartners.com\/wp-json\/wp\/v2\/comments?post=1681"}],"version-history":[{"count":0,"href":"https:\/\/www.ioipartners.com\/wp-json\/wp\/v2\/posts\/1681\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.ioipartners.com\/wp-json\/wp\/v2\/media?parent=1681"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.ioipartners.com\/wp-json\/wp\/v2\/categories?post=1681"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.ioipartners.com\/wp-json\/wp\/v2\/tags?post=1681"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}