Nesta seção da lógica estamos descrevendo as categorias de processo. No final de cada categoria apresentamos uma lista de práticas, que inclui metodologias, das quais podemos derivar processos de inovação.

Exemplos de processos de negócio primários end-to-end (ponta a ponta) de inovação já foram listados em alguns tópicos da flexM4I e repetimos aqui:

• planejamento estratégico
• planejamento da inovação
• desenvolvimento (design) de produtos
• desenvolvimento (design) de serviços
• desenvolvimento (design) da experiência do usuário
• desenvolvimento de clientes
• desenvolvimento (design) de sistemas produto-serviço
• desenvolvimento de tecnologia
• inovação do modelo de negócio

As descrições dos processos de planejamento estratégico e planejamento da inovação fazem parte da lógica, porque são processos que agregam muitas inovações. Eles correspondem a duas categorias  de processos, pois dependem da abordagem e metodologia adotada. Ou seja, podemos descrever a lógica genérica, mas um processo de uma empresa será diferente dos processos de outras empresas.

Os demais processos listados são processos primários realizados por meio de projetos. Consulte o tópico “Processo de negócio versus Projeto (project) e Operação” para conhecer essa definição de processo.

Os processos de apoio fazem parte de uma outra categoria processos da lógica da inovação.   

Complemente seus conhecimentos sobre processos, visitando os tópicos:

• gestão de (por) processos desta seção da  lógica da inovação e
• gestão da inovação e a gestão por processos da seção “gestão da inovação”

Novamente recomendamos conferir a seção que traz exemplos de metodologias e modelos de processo.

Como dissemos, toda representação é limitada. Na figura do framework da perspectiva de processo, colocamos várias flechas que representam projetos. 

Criamos várias flechas curvas para indicar que as atividades do projeto interagem com as seguintes categorias de processo:

• gerenciar ecossistema de inovação
• experimentar, avaliar selecionar, aprender e pivotar
• gerenciar pessoas, organização e processos de apoio transversais

Então, a representação de um projeto de inovação seria a que está ilustrada na próxima figura.

Representamos essas categorias em barras separadas, ao invés de considerá-las parte de um projeto, para enfatizar a importância dos seus processos. Repetir a figura acima várias vezes na figura do framework, a deixaria muito poluída. Então, optamos por repetir somente a figura das flechas únicas que representam um projeto. 

Qual o significado dessa figura acima? Que um projeto de inovação contém atividades relacionadas com essas categorias de processo, como ilustrado na próxima figura.

Figura 412: Um projeto de inovação é composto por atividades derivadas de diversos processos.

Observações sobre a figura:

• as atividades dos projetos são variadas conforme discutiremos no tópico sobre as fases de desenvolvimento de um projeto mais a frente;
• nem todas atividades de um projeto pertencem a essas categorias, pois existem atividades relacionadas com as entregas tecnológicas específicas de cada projeto;
• algumas atividades dos processos dessas categorias ocorrem fora do escopo de um projeto (por exemplo, gerenciar a organização inclui acompanhar indicadores de desempenho de resultados para definir bônus dos colaboradores)
• essa figura não representa os ciclos iterativos e pode passar a impressão que um projeto de inovação é linear
• apesar das atividades “experimentar, avaliar selecionar, aprender e pivotar” serem realizadas dentro de um projeto, temos uma categoria separada para elas
• descreveremos as atividades das quatro categorias da figura anterior em tópicos separados

Recorde a discussão da multidisciplinaridade na inovação (veja a seção “disciplinas relacionadas com a inovação”). Por isso repetimos a seguir a figura, que representa as atividades de um processo de inovação advindas de muitas disciplinas. Utilizamos a mesma figura  na seção “marketing e inovação”, quando destacamos que não são somente atividades de marketing que fazem parte de um processo de inovação.

Como os projetos são derivados dos processos, se existir uma formalização mínima de processos de inovação (tipo um checklist), será mais fácil não esquecer nada no momento de planejar um projeto. Mas mesmo nesse caso, as atividades podem pertencer a mais de um processo, que na verdade será considerado nesses casos um subprocesso da inovação ou um processo de apoio transversal (veja a seção final desta seção).

Um exemplo para ilustrar essa estruturação dos processos está na próxima figura, copiada do tópico “Integração dos processos de apoio aos processos de negócio primários” da terminologia. 

A figura ilustra, de forma conceitual, a distribuição de atividades (retângulos pretos) sob responsabilidade de diferentes:

• processos de apoio e/ou
• funções de negócio e/ou
• áreas organizacionais

pela fases de um processo de desenvolvimento de produtos.

Os artefatos são gerados ao longo do projeto. No início desta seção foram apresentados os principais artefatos genéricos. Existem artefatos intermediários e finais (veja figura abaixo). Esses artefatos são chamados de entregas (deliverables) do projeto.

Veja as definições de artefato, artefato concreto e artefato conceitual no glossário.

Exemplos de artefatos intermediários: lista de requisitos, modelos gráficos, persona, mapa da jornada, anotações de entrevistas, modelos CAD, modelos de simulações, estrutura do produto (BOM -bill of material), documentos de gerenciamento de projetos, orçamentos etc. A maior parte desses artefatos corresponde a modelos digitais. Eles são, portanto, artefatos conceituais.

Artefatos podem ser a base para se obter outros artefatos (linhas pontilhadas na figura).

Por exemplo, o mapa de stakeholders serve para definir as personas que serão analisadas; a lista de requisitos é usada para se especificar as características de um produto; etc. 

Os artefatos intermediários podem servir de base para a obtenção de um artefato final. O conjunto dos artefatos finais é o resultado concreto do projeto. Chamamos de resultado “concreto” para diferenciar de outros resultados, como os relacionados com os objetivos, que possuem metas mensuráveis por métricas (veja o tópico, objetivos da inovação do capítulo estratégia e objetivos da inovação).

Por exemplo, o resultado de um projeto de inovação pode ser um novo processo produtivo utilizando IoT para transmitir dados de operação e permitir a manutenção preditiva. O resultado mensurável, objetivo da inovação, seria o menor tempo de atendimento para resolver paradas de máquina, ou o menor custo hora da máquina devido a um menor número de panes na operação sem atendimento graças à manutenção preditiva.

O conteúdo deste tópico foi adaptado do PMI (2021).

Uma abordagem de desenvolvimento de um projeto é a forma pela qual os artefatos (entregas do projeto) são criados e evoluem durante o ciclo de vida de um projeto.

Existem três tipos de abordagens de desenvolvimento de um projeto:

• preditiva (que também denominamos  planejável)
• híbrida
• adaptativa (que também denominamos ágil)

A forma de evolução das entregas, que depende da sua natureza, pode ser iterativa ou incremental.

A figura a seguir ilustra a relação entre essas abordagens e formas.

Fonte: adaptado de PMI (2021)

A abordagem preditiva é usada quando os requisitos, escopo, custo, recursos necessários e riscos podem ser definidos nas fases iniciais do projeto e essas informações  permanecem relativamente estáveis durante o projeto. Essa abordagem de desenvolvimento permite que o nível de incerteza seja reduzido nas fases iniciais e, por isso, seja planejável desde o início. Essa abordagem pode usar projetos exploratórios para avaliar opções. Mesmo assim, a maior parte do trabalho segue o planejamento inicial.

A abordagem adaptativa é usada quando os requisitos possuem um grau elevado de incerteza e volatilidade e mudam durante o projeto. Uma visão é estabelecida no início do projeto e os requisitos conhecidos no início do projeto são refinados, detalhados, modificados e substituídos de acordo com o feedback do usuário, ambiente ou eventos inesperados. As entregas podem evoluir de forma iterativa e incremental. Quanto mais adaptativo for o desenvolvimento, mais curtam as iterações tendem a ser . A evolução dos artefatos é baseada no feedback dos stakeholders. O time do projeto planeja o escopo de cada iteração baseado em um backlog de entregas priorizadas.

A abordagem híbrida é uma combinação das abordagens preditiva e adaptativa. Essa abordagem é usada quando existe incerteza e riscos com relação aos requisitos. Essa abordagem é útil quando se consegue modularizar as entregas ou quando as entregas podem ser atribuídas a times diferentes. Essa abordagem, por exemplo, pode usar princípios da adaptativa no início do desenvolvimento , quando existem muitas incertezas. Nas fases subsequentes de detalhamento pode usar a abordagem preditiva, desde que haja mais certeza. Pode também usar princípios e ferramentas de abordagens preditivas para definir os marcos dos projetos, apesar da incerteza, e realizar as atividades com base na abordagem adaptativa.

A forma iterativa de se obter as entregas é utilizada quando se testa (explora) várias opções de entregas  para esclarecer o escopo e requisitos. É quando se obtém, em cada iteração, um maior conhecimento sobre as entregas e as condições determinantes do projeto.

Por exemplo, quando se explora diferentes opções de como interagir com os clientes ou de como entregar uma funcionalidade.

A forma incremental é usada para produzir um artefato (entrega) através de uma série de iterações. Ou seja, cada iteração adiciona uma funcionalidade ou um conteúdo à versão anterior da entrega, resultante da iteração anterior. O artefato só é considerado finalizado depois da última iteração.

Por exemplo, o desenvolvimento de um software pode acrescentar uma funcionalidade a cada iteração.

Apesar da primeira forma ser denominada iterativa, em ambos os casos o desenvolvimento ocorre por meio de iterações.

As atividades de um projeto podem ser agrupadas em fases (próximo tópico).

Somente quando um projeto possuir um escopo maior podemos agrupar suas atividades em fases. Em projetos exploratórios, rápidos, mais simples e na abordagem de desenvolvimento adaptativa, não faz sentido definir fases.

Fase é um conceito da gestão de projetos (veja a figura a seguir). Uma fase está associada a um ciclo de vida de um projeto. “A fase de um projeto é um conjunto de atividades logicamente relacionadas que culmina na conclusão de uma ou mais entregas. As fases podem ser sequenciais, iterativas ou sobrepostas” (PMI, 2017).

Existe uma grande variedade de fases da inovação que, normalmente, estão relacionadas com os fatores contextuais, mas principalmente com:

• setor;
• tecnologia;
• o objeto de inovação (produto, serviço, modelo de negócio, estrutura organizacional etc.) e
• grau de novidade.

Ou seja, as fases dependem da tipologia do projeto e seus fatores contextuais.

Em projetos recorrentes com escopos maiores podemos adotar e/ou definir um modelo de processo para a nossa empresa, que serve de referência para se definir o escopo desses projetos recorrentes. Assim, não esqueceremos de especificar nenhuma atividade do projeto. É um tipo de checklist para a definição do escopo / backlog do projeto. 

Esse modelo de processo de uma empresa pode ser definido com base na experiência ou em metodologias, modelos de referência, corpo de conhecimentos (BoK – body of knowledge).

Na seção “metodologias e modelos de processo” diferenciamos os termos citados acima e trazemos alguns exemplos de modelos de processo.

Normalmente, as entregas resultantes de uma fase são avaliadas em um gate (próximo tópico)

Como o conceito de fase está associado com a conclusão de algumas entregas, após a finalização de uma fase pode ocorrer uma avaliação (gate) para decidir se o projeto deve continuar, congelar, aguardar, mudar de rumo ou ser cancelado. Em outras palavras, a empresa decide se continua a investir, ou não, no desenvolvimento daquele projeto (quando não for sob encomenda). No gate é avaliado se as entregas desejadas ou os critérios de aprovação da fase foram atingidos. Esses critérios podem ser critérios de aceitação das entregas, obrigações contratuais, metas de desempenho específicas ou outro resultado tangível mensurável.

No caso de produtos complexos e que demandam grandes investimentos nos protótipos funcionais (por exemplo, no desenvolvimento de aeronaves ou automóveis), a fase de detalhamento pode ser dividida em duas: detalhamento com teste virtual e detalhamento com teste do protótipo real.

Definir antes a fase ou o gate?

Você pode se perguntar se definimos primeiramente o gate ou a fase. É o gate, ou melhor, quais entregas você deseja avaliar. Uma vez definidas quais entregas você considera importante agrupar para avaliar, a fase é o conjunto de atividades que produzem essas entregas.

Realizar gate em projetos ágeis da abordagem de desenvolvimento adaptativa?

Algumas pessoas argumentam que os gates não agregam valor ao fluxo da inovação e representam um desperdício. Por isso não deveriam ser utilizados principalmente em projetos ágeis. É verdade. Se o projeto for de curta duração e com um escopo pequeno, o gate só introduz uma burocracia adicional. Provavelmente devem existir reuniões bem frequentes para avaliar o andamento do projeto. 

Em grandes empresas, para projetos com escopos maiores, projetos sensíveis e estratégicos, os gates são momentos em que a alta direção se envolve com a inovação. Deve-se preocupar em não burocratizar demais o processo de gate. No entanto, se as reuniões de gate forem ineficazes e os dirigentes não se envolverem de verdade, não vale a pena realizá-los. É comum avaliar o andamento de grandes projetos, com o envolvimento dos dirigentes, nas revisões periódicas do portfólio.

Se durante os últimos gates de projetos não ocorreu um redirecionamento ou mesmo um cancelamento, essa avaliação fica desacreditada e ninguém mais vê valor nessa prática. 

Experimente realizar gates para alguns projetos e veja se essa prática se torna eficaz na sua empresa.

Comitê de gates como investidores de capital de risco

Como a tendência é hoje unificar os processos de desenvolvimento / inovação com o processo de desenvolvimento de clientes, como o de lean startup (Ries, 2011) ou o modelo do Blank & Dorf (2012), muda também o conceito de gate.

Apesar das referências citadas serem focadas em startups, alguns desses princípios são utilizados em empresas estabelecidas (incumbent) para inovações mais radicais dentro do contexto da inovação ambidestra.

No innovation stage-gate, os membros do comitê de avaliação do projeto de inovação devem se comportar, nos gates, com  a mentalidade (mindset) de investidores de capital de risco. Veja neste artigo uma proposta de 8 princípios para poder praticar essa nova versão de gates.

Ele representa a série de fases pelas quais um projeto passa, do seu início até a finalização (PMI, 2021). Pode também ser derivada dos modelos de processo citados no tópico sobre “fases”.

A articulação das atividades de um ciclo de vida de projeto depende da abordagem de desenvolvimento (PMI, 2021): 

• na abordagem preditiva, geralmente, uma fase inicia após o término da fase anterior, se ela foi aprovada no gate. Normalmente, cada fase contém um tipo específico de trabalho;
• na abordagem adaptativa, não se fala em fases. No final de cada iteração (sprint), os stakeholders chave revisam as entregas, dão um feedback, e o time do projeto atualiza o backlog ao priorizar as entregas ou funções da próxima iteração. A programação das atividades é baseada no fluxo de valor e não em ciclo de vida ou fases. Nessa abordagem, os objetivos são: otimizar o fluxo de valor, com base na capacidade dos recursos; minimizar os tempos, os desperdícios; e aumentar a eficiência dos processos (com base na abordagem lean).

Não confunda ciclo de vida de um projeto com o ciclo de vida de uma oferta (produto ou serviço). Diferentes critérios podem definir ciclos de vida distintos; mas está fora do escopo deste tópico discutir os tipos de ciclos de vida.

Os projetos da abordagem de desenvolvimento preditiva são orientados pelo escopo. Escopo é a soma dos produtos, serviços e resultados de um projeto (PMI, 2021). Na área de gestão de projeto existem uma diferenciação entre:

• escopo do produto (resultado de um projeto): as características e funções de um produto, serviço ou resultado
• escopo do projeto:  o trabalho necessário para entregar o escopo do projeto 

 No caso de inovações incrementais, quando se consegue planejar porque há pouca incerteza, é possível definir o escopo do projeto. A descrição de escopo tradicional é suficiente para orientar o desenvolvimento do projeto.

Em projetos da abordagem adaptativa de desenvolvimento, normalmente o escopo do produto não está claro no início do projeto, devido às incertezas inerentes a este tipo de abordagem. Portanto, não é possível definir o escopo do projeto.

Nessa abordagem adaptativa, um projeto de inovação é orientado por uma visão, que é uma prática muito difundida desde a popularização do paradigma da gestão ágil de projetos.

Os métodos desses dois paradigmas podem ser combinados para se criar uma metodologia de gestão híbrida de projetos (Bianchi et al. al., 2021). De acordo com o nível de conhecimento dos requisitos e incerteza, o projeto como um todo pode ter um escopo ou uma visão. Ele pode ser dividido em módulos e alguns terem escopo e outros visão. 

Por exemplo, imagine que você está construindo um centro de inovação separado da organização atual em um outro local para definir projetos de inovação disruptivos. A construção civil do centro com certeza terá um escopo e a definição do portfólio inicial de projetos uma visão.

Visão é um conceito da gestão de projetos. Quando já temos alguma noção sobre as características da situação futura, somos capazes de propor uma visão, mesmo que seja de forma aproximada e ambígua. Ela orienta um projeto. A definição a seguir é a de visão de um projeto de produto, que podemos usar como referência para explicar seu uso no contexto da lógica de inovação (consulte a discussão sobre ambiguidade do termo visão). 

Visão é uma representação textual e/ou visual clara e concisa  do que deve ser atingido no projeto, podendo incluir características do mercado alvo e antecipar determinadas características da solução (REID; DE BRENTANI, 2010; BENASSI et al., 2013).

A tabela a seguir mostra possíveis visões com base nos desafios estabelecidos nos exemplos de desafios apresentados anteriormente.

Um desafio concreto confunde-se com a visão, ou seja, quando você já tiver uma noção mais concreta do resultado final que deseja atingir. É uma característica típica de inovações incrementais, que na verdade já pode ter uma descrição do escopo, como mencionado anteriormente.

No exemplo da melhoria de processo (na tabela acima), pode acontecer que a pessoa da manufatura, que propôs a melhoria, já tenha descrito as características e indicadores de sucesso, no momento em que formulou a ideia, que se reflete no desafio /  visão / escopo. 

Não complique. Não exija que todos os projetos de inovação tenham uma divisão clara e sempre presente entre ideia, desafio e visão. Seja flexível!

Quanto mais abstrato o desafio (“desafio de alto nível”), provavelmente porque existem muitas incertezas sobre o futuro, mais difícil caracterizá-lo na visão, que direcionaria o projeto de inovação.  A “ideia/desafio” inicial, que foi o gatilho para este projeto, talvez seja do tipo “vamos analisar essa possibilidade” ou “vamos explorar essa oportunidade” ou “vamos eliminar esse problema”. Ou seja, foi uma ideia / desafio muito abstrato. Ideias mais concretas da solução ainda devem surgir durante a realização do projeto de inovação. Podem ser realizados projeto exploratórios para definir a visão do projeto de inovação (veja o próximo tópico).. 

As atividades de um projeto podem ser realizadas de forma iterativa ou mesmo em ciclos. Se a visão for muito abstrata no início do projeto, conforme as iterações forem ocorrendo, você pode atualizar a visão e deixá-la mais concreta.

Apesar de existir a possibilidade de se ter escopo ou visão como um direcionador de um projeto, no resto desta seção utilizaremos o termo “visão” para enfatizar o caso de projetos adaptativos e não preditivos. Este é o caso de projetos de inovação mais radical e disruptiva, mas também de alguns projetos de sustentação e melhoria da excelência operacional.

Projetos exploratórios podem ser realizados para:

• criar a visão e definir as hipóteses de um projeto de inovação
• validar hipóteses e 
• realizar uma prova de conceito 

Projeto exploratório para criação de visão e definição de hipóteses

Quando falamos da relação desafio e visão, comentamos também sobre desafios muito abstratos, resultantes de ideias bem amplas sem a proposição de soluções, mas sim com a identificação de problemas e oportunidades. Por isso, é possível que entre o desafio e a visão tenhamos que realizar “um projeto exploratório”. Em outras palavras, neste caso vamos investir tempo e esforço para definir melhor as hipóteses e criar a visão.

Este “projeto exploratório” deve ser de baixo custo, pelo menos bem menor do que o projeto principal. Assim, conseguimos ter um pouco mais de certeza para seguir em frente.

Como visão é um constructo que direciona a realização do projeto, esse “projeto exploratório” também tem uma “visão”, que é obter a visão do “projeto principal” (e provavelmente uma confirmação de uma hipótese inicial que permita que o projeto seja realizado), como ilustramos a seguir.

A próxima figura ilustra os possíveis conceitos / informações criadas nas fases iniciais de um projeto de inovação, que podem ser documentadas em artefatos distintos. O objetivo dessa figura é destacar os dois tipos de visão, do projeto exploratório e do projeto de inovação. Os termos em azul representam possíveis etapas / categorias de processo.

A lógica é recursiva

Na verdade, essa lógica é recursiva. Recursividade é uma propriedade de um objeto ou um processo ser repetido da mesma forma por um número indefinido de vezes. No nosso caso, significa que você realiza um projeto exploratório (investe tempo e esforço) para obter a visão do “projeto principal”. Procuramos representar a recursividade na próxima figura. É uma outra forma de representar a figura anterior.

A visão do projeto principal é determinada após a realização do “projeto exploratório” no início do projeto. É o que descrevemos anteriormente, representado como uma lógica recursiva.

Projetos exploratórios para validação de hipóteses

No caso de um desafio amplo (por exemplo, criar uma nova oferta para um mercado específico) perante muita incerteza (típico de uma inovação disruptiva ou mais radical), podemos ter hipóteses distintas que levam à realização de alguns projetos exploratórios de baixo custo para que possamos validar as hipóteses e diminuir, portanto, os riscos associados a incertezas. Nesses casos, os projetos envolvem a criação de protótipos com diversos níveis de detalhamento e muita experimentação. Como é ilustrado abaixo.

Na presença de incertezas, você vai falhar várias vezes antes de acertar. Ops! Falhar não, aprender. Por isso, invista pouco em pequenos projetos, experimente e valide algumas hipóteses iniciais antes de continuar.

Projetos exploratórios para construção de uma prova de conceito (POC)

POC é semelhante ao que descrevemos no tópico anterior. É quando construímos um protótipo que “prova” que o conceito inicial (da visão por exemplo) é factível. Muitas vezes, mesmo após a POC, as fases subsequentes de desenvolvimento podem apresentar limitações que inviabilizam o projeto. Ou seja, em inovações mais radicais, a taxa de sucesso dos projetos exploratórios é baixa. Para isso, a liderança deve ter tolerância a falhas.

Você deve estar colocando a pergunta acima. Na gestão ágil não poderíamos definir um sprint (iteração) para se chegar na visão? Ou mesmo simplesmente criar a visão antes de chamar de projeto? Sim, você tem razão.

Nossa proposta para determinar se seria um “projeto exploratório” ou uma atividade depende de qual o  esforço “temporário” necessário para se chegar na visão e quem irá realizar. Se for algo rápido, sem muito esforço dentro do “planejamento da inovação”, não precisa ser um projeto.

Essa questão também está relacionada com a estrutura organizacional que realiza o “planejamento da inovação”. Se existir uma área dedicada a definir escopos de projetos futuros (e, portanto,  as visões correspondentes), essas atividades podem fazer parte do processo operacional da área e não precisam ser tratadas como um projeto. Mas, se for demorado chegar na visão do projeto principal, realiza-se um “projeto exploratório”.

Às vezes, um time é responsável por realizar “projetos exploratórios” e outro pelo projeto principal.

Conforme o tamanho do projeto e incertezas, vale a pena realizar este “projeto exploratório” inicial. São realizados ciclos e talvez existam momentos de pivotar, até conseguir provar as hipóteses de valor e de mercado, ou seja, desenvolver os clientes e o mercado (veja o próximo tópico). Em seguida, o projeto de detalhamento e implementação pode fazer parte do escopo de um outro projeto.

As possíveis combinações dependem dos fatores contextuais do seu caso específico.

É bem complicado propor atividades genéricas dos projetos de inovação,  como você pode ver pela variabilidade de modelos de processo e fases na seção “metodologias e modelos de processo”. Lembre que fase é um conceito de gestão de projetos.

As atividades genéricas de um projeto são:

• entender: no sentido mais amplo é obter informações sobre o contexto da inovação (mercado, concorrentes, tecnologia, tendências) sintetizando ou complementando as informações dos processos da categoria “rastrear, monitorar e analisar o contexto”. O entender desce a um nível mais detalhado e focado, pois ocorre após a definição da ideia / desafio. O objetivo principal é entender os stakeholders (com foco no cliente, mas temos de criar valor não somente para os clientes) para definir oportunidades, desejos, necessidades, dores e problemas, assim como obter insights. Nesse momento podem ser definidas várias hipóteses a serem testadas com a avaliação e experimentação;
• criar: é quando surge a inovação, tanto o seu conceito nas fases iniciais, como a sua arquitetura antes do detalhamento. É o momento crucial de criação de valor. A criatividade é uma competência essencial neste moment;
• experimentar, avaliar, selecionar, aprender e pivotar: descritas no tópico sobre essa categoria de processos (veja também porque criamos uma categoria separada);
• detalhar: enquanto a criação foi o momento de inspiração, o detalhamento é o da transpiração. O detalhamento pode demorar muito tempo em alguns tipos de inovação. Principalmente se forem inovações complexas com o emprego de muitas tecnologias inovadoras e se tiverem de seguir regulamentações exigentes. O que foi concebido na etapa de criação precisa ser especificado e aprovado.  As especificações da inovação (resultado) e da cadeia de valor são finalizadas visando a implementação;
• implementar: este é o momento da inovação se tornar real, “sair do papel”. Você implementa a inovação considerando todas as perspectivas da empresa. Inclui o lançamento da inovação e o acompanhamento da fase inicial de uso.

As atividades de entender e criar podem ser realizadas dentro do planejamento da inovação, como um “projeto exploratório”.

Em projetos de desenvolvimento de software a etapa de detalhar já se inicia com o criar e confunde-se com a etapa de implementação.  A evolução das entregas de um projeto deste tipo pode ser iterativa ou incremental (dentro do tópico “abordagens de desenvolvimento de um projeto”).  Depois da implementação existiria ainda uma fase de implantação da solução no negócio. Mas essa é uma discussão semântica. Podemos tratar essas etapas como implementação.

Nas inovações de produtos mais complexos, como bens de capital, por exemplo, a etapa de detalhar pode ser bem demorada e é subdividida em várias fases, como mostram alguns exemplos da seção “metodologias e modelos de processo”.

Os projetos de inovação podem ter durações variadas, de algumas semanas até meses ou alguns anos, dependendo da complexidade da inovação. Essa é mais uma razão para se aplicar a gestão híbrida de projetos, na qual os grandes marcos dos projetos são definidos com base em métodos da abordagem preditiva e o trabalho semanal é gerenciado de forma ágil e adaptativa.

Duração de um projeto

Gross et al. (2018) estudaram inovações na área de geração de energia passando pelos estágios de invenção, desenvolvimento, demonstração, aceitação pelo mercado e comercialização de produtos, que incluíam o desenvolvimento e maturação da tecnologia. Em média, as inovações duraram 32 anos para atingirem um nível elevado de maturidade 

Compare a duração de desenvolvimento de um App para um celular, com a duração de desenvolvimento de um automóvel, uma aeronave ou um novo fármaco. 

• App (varia conforme a complexidade): 4 a 8 meses
• automóvel: 4 a 8 anos (veja uma discussão sobre isso na web)
• aeronave: 6 a 11 anos (veja uma comparação neste link)
• fármaco: 10 a 15 anos (veja a apresentação das fases de desenvolvimento neste link)

Usar uma referência para planejar um projeto?

As pessoas com mais experiência utilizam seu repertório para inovar, ou seja, elas já estão acostumadas a empregar métodos e ferramentas de inovação. Elas não precisam de referência alguma para inovar. Mas a empresa fica dependente do conhecimento tacito das pessoas com experiências. Ao mesmo tempo, com o potencial de novas tecnologias, principalmente as digitais, esse conhecimento tácito pode estar limitado a inovações. 

Como combinar o conhecimento tácito profundo de pessoas mais experientes sobre as tecnologias específicas da empresa com o conhecimento sobre tecnologias digitais de novos colaboradores? Essa é uma questão da gestão do conhecimento tratada no capítulo sobre gestão da inovação.

Uma das maneiras de se registrar (explicitar) os conhecimentos é documentando práticas em modelos de processo. A especificação de atividades ou entregas de projeto de inovação podem ser derivadas das atividades e/ou entregas documentadas em um modelo (de referência) do processo de inovação da sua empresa (se ele estiver formalizado). Temos, no entanto, de ter cuidado para não engessar a inovação e “matar” a criatividade, pois esses modelos prescrevem como a sua empresa inova. Essa discussão está na seção “metodologias e modelos de processo” do capítulo de conceitos.

Alguns modelos de processo abrangem também as atividades do planejamento da inovação. No entanto, como os modelos de processo geralmente são voltados para um tipo de oferta, as fases equivalentes ao planejamento da inovação são enviesadas para o tipo de oferta do modelo. Esta  é a razão pela qual definimos na flexM4I o planejamento da inovação como uma categoria de processo separada.

Fases de um projeto de inovação 

As atividades dos projetos de inovação podem ser agrupadas em fases, como mostramos anteriormente. Assim como as durações são variadas, existem muitas fases distintas que cada tipo de inovação passa desde a sua criação até a comercialização. Na seção sobre “metodologias e modelos de processo” apresentamos vários exemplos de fases.

Como mencionado anteriormente, não esqueça que para projetos gerenciados pela abordagem adaptativa de desenvolvimento não faz sentido falar em fases.

Vimos que a definição de fases é um conceito de gestão de projetos e que possui uma grande variabilidade dependendo do tipo de projeto e fatores contextuais. Existem dois termos que abrangem essas quatro etapas de diferentes formas, que no fundo não representam fases, mas sim macrofases da inovação.São os termos design e desenvolvimento. A próxima figura ilustra essas diferentes formas.

Existem os seguintes usos dos termos design e desenvolvimento:

O termo design & desenvolvimento indica que:

• o design abrange o entender e criar e pode ocorrer tanto no planejamento da inovação como depois
• no planejamento da inovação o design pode ser realizado por meio de um projeto exploratório 
• o desenvolvimento abrange o detalhamento, mas as vezes engloba também a implementação e pode ser realizado por meio de um projeto de inovação

O termo desenvolvimento pode abranger as quatro etapas, assim como o termo design, usando neste caso como sinônimo de desenvolvimento.

Escolha o termos mais apropriado para a cultura da sua empresa, mas não esqueça de relacionar com essas etapas genéricas e articular com o framework da perspectiva de processo ao definir a arquitetura de processos da sua empresa.

Neste tópico apresentamos uma lista de poucos exemplos de abordagens, metodologias, métodos e ferramentas relacionados com esta categoria. Consulte a síntese da perspectiva de processo para acessar uma lista mais completa e informações adicionais sobre essas práticas.

Essas práticas podem servir de referência para a sua empresa: adotar alguns dos seus princípios; definir seus processos; implementar alguns métodos e ferramentas de inovação.

Como é por meio de projetos que se realiza a inovação, existem muitas práticas e não conseguiremos listar todas aqui. Não iremos listar práticas específicas relacionadas com as tecnologias de cada produto e serviço desenvolvido. Veja aqui uma lista de tecnologias conhecidas, emergentes e tendências tecnológicas.

Cada combinação setor + tecnologia possui suas práticas de criação de artefatos concretos e conceituais, que seriam empregadas nos projetos de desenvolvimento desses artefatos. Algumas práticas da lista a seguir são bem amplas e outras correspondem a processos de apoio transversais.

• Análise de investimentos 
• Branding
• Confiabilidade
• Data analytics
• Desenvolvimento (design) de produtos 
• Desenvolvimento (design) de serviços
• Desenvolvimento de clientes
• Desenvolvimento virtual (CAx)
• Design
• Design da proposição de valor
• Design de sistemas produto-serviço (PSS) 
• Design for X (DfX)
• Design methodology
• Design sprint
• Design sustentável 
• Design thinking
• Digitalização
• Ecodesign 
• Economia circular
• Engenharia de sistemas (Systems engineering)
• Engineering Change Management (ECM)
• Engineering Design
• ESG: environmental, social & corporate governance
• Experience Innovation
• Experimentação e prototipagem
• Gestão ágil de projetos
• Gestão da configuração (configuration management)
• Gestão da qualidade: PDCA
• Gestão de mudança
• Gestão de projetos
• Gestão do custo-alvo
• Gestão híbrida de projetos
• Impressão 3D
• Indústria 4.0
• Industrial design 
• Inovação do modelo de negócio 
• Lean design 
• Lean Startup
• Lean: Kaizen
• Precificação
• Projeto de experimentos (DOE: design of experiments)
• Simulação 
• Six sigma: DMAIC
• Stage-gate 
• Sustentabilidade
• Teoria baseada em recursos
• Teoria da utilidade
• Teoria da utilidade
• Teoria do valor percebido
• Tomada de decisão
• User Centered Design (UCD)
• User experience (UX) design
• Valuation