Gestão de projetos de inovação - oitonovetres.com.br€¦ · A chegada da era da computação também trouxe a sua contribuição, com o lançamento de inúmeras ferramentas para

Universidade do Sul de Santa Catarina

Gestão de projetos de inovação

AutorMauro Faccioni Filho

Créditos

Universidade do Sul de Santa Catarina – UnisulReitorSebastião Salésio HerdtVice-ReitorMauri Luiz Heerdt

Pró-Reitor de Ensino, de Pesquisa e de ExtensãoMauri Luiz HeerdtPró-Reitor de Desenvolvimento InstitucionalLuciano Rodrigues MarcelinoPró-Reitor de Operações e Serviços AcadêmicosValter Alves Schmitz Neto

Diretor do Campus Universitário de TubarãoHeitor Wensing JúniorDiretor do Campus Universitário da Grande FlorianópolisHércules Nunes de AraújoDiretor do Campus Universitário UnisulVirtualFabiano Ceretta

Campus Universitário UnisulVirtual

DiretorFabiano Ceretta

Unidade de Articulação Acadêmica (UnA) – Ciências Sociais, Direito, Negócios e ServiçosAmanda Pizzolo (coordenadora)

Unidade de Articulação Acadêmica (UnA) – Educação, Humanidades e ArtesFelipe Felisbino (coordenador)

Unidade de Articulação Acadêmica (UnA) – Produção, Construção e AgroindústriaAnelise Leal Vieira Cubas (coordenadora)

Unidade de Articulação Acadêmica (UnA) – Saúde e Bem-estar SocialAureo dos Santos (coordenador)

Gerente de Operações e Serviços Acadêmicos Moacir HeerdtGerente de Ensino, Pesquisa e ExtensãoRoberto IunskovskiGerente de Desenho, Desenvolvimento e Produção de Recursos Didáticos Márcia LochGerente de Prospecção Mercadológica Eliza Bianchini Dallanhol

Livro Digital

UnisulVirtualPalhoça, 2016

Designer instrucionalMarina Melhado Gomes da Silva

Mauro Faccioni Filho


Livro Digital

Copyright © UnisulVirtual 2016

Professor conteudistaMauro Faccioni Filho

Designer instrucionalMarina Melhado Gomes da Silva

Projeto gráfico e capaEquipe UnisulVirtual

DiagramadorNoemia Mesquita

RevisorDiane Dal Mago

Nenhuma parte desta publicação pode ser reproduzida por qualquer meio sem a prévia autorização desta instituição.

Ficha catalográfica elaborada pela Biblioteca Universitária da Unisul

F12Faccioni Filho, Mauro

Gestão de projetos de inovação: livro digital/Mauro Faccioni Filho; design instrucional Marina Melhado Gomes da Silva. – Palhoça: UnisulVirtual, 2016.65 p. : il. ; 28 cm.

Inclui bibliografia.

1. Administração de projetos. I. Silva, Marina Melhado Gomes da. II. Título.

CDD (21. ed.) 658.404

Sumário

Apresentação | 5

Capítulo 1 E então, o que é um projeto de inovação? | 7

Capítulo 2 Quem consegue conduzir um projeto de inovação? | 16

Capítulo 3 Os métodos tradicionais de gestão de projetos valem a pena? | 26

Capítulo 4 O guia PMBOK tem alguma utilidade? | 43

Capítulo 5 Há métodos especiais para a gestão de projetos de inovação? | 60

Considerações finais | 63

Sobre o conteudista | 64

Apresentação

A gestão de projetos é um tema relevante nas últimas décadas. Muitos métodos, modelos, teorias, processos e experiências foram conduzidos na tentativa de melhorar, em especial, prazos e custos de projetos. Mas o sucesso tem sido muito relativo, e até mesmo podemos falar em grandes fracassos, como veremos.

Outro tema relevante é o da inovação. O assunto entrou na pauta mais ou menos na época da revolução da computação, pois o crescimento vertiginoso das companhias digitais americanas, e mais ainda aquelas do Vale do Silício, chama a atenção por seu caráter de criação constante de novas soluções e ideias com impacto comercial. As maiores empresas do mundo estão ali, nesse ambiente. Como fazem para ter esse ambiente inovador, e como se dá a gestão de tantos projetos de sucesso?

Este livro pretende, neste sentido, funcionar como uma provocação para a reflexão sobre como fazer a gestão de projetos de inovação, como fazer com que ideias novas possam se transformar em algo concreto e viável, que tenha foco num público, e que esse público queira, afinal, investir nesses produtos.

Por esse motivo, o livro se divide em questões. A primeira delas é: afinal, o que é um projeto de inovação? O que é um projeto, e o que determina sua inovação? Aliás, há tipos diferentes de inovação? A segunda questão diz respeito às pessoas que fazem a gestão, ou seja, quem consegue conduzir um projeto de inovação? Isso é tarefa para gerentes de projeto convencionais?

Falando em projetos convencionais, quais seriam os métodos tradicionais de gestão de projetos? E esses métodos valem a pena quando falamos de inovação? Entre os gerentes de projeto há uma certificação internacional bastante conhecida, oriunda do PMI (Project Mangement Institute), que está baseada em um guia de gestão de projetos intitulado PMBOK (Project Management Book of Knowledge). Esse guia, o PMBOK, tem alguma utilidade real para os projetos de inovação? Essa é a quarta questão levantada no livro, e para isso vamos discutir alguns dos principais tópicos de gerenciamento que o PMBOK coloca como fundamentais na gestão de projetos.

A quinta e última provocação do livro nos coloca: afinal de contas, há métodos especiais para a gestão de projetos de inovação? E quem disse que, usando esses métodos, o projeto de inovação vai dar certo?

Vamos usar essas questões para conduzir este livro, em si mesmo, como um projeto de inovação. Que tal?

Prof. Mauro Faccioni Filho.

Capítulo 1

E então, o que é um projeto de inovação?

Conceitos e discussões iniciaisA palavra “projeto” é interpretada de muitas maneiras pelas pessoas. E muitas dessas maneiras não dizem respeito ao “projeto”, como vamos tratar aqui. Para alguns, o projeto pode ser o desenho de uma construção ou de um produto. Outros denominam um “projeto de vida” ao se referirem à intenção de viver de um determinado jeito, ter uma família, fazer um negócio etc. São conceitos difusos, que desvirtuam a noção da gestão de projetos.

Da mesma forma, há certa confusão quando se trata da palavra “inovação”. Alguns consideram qualquer novidade como inovação, outros entendem que apenas os produtos completamente fora dos padrões já conhecidos é que seriam inovações. Há um grande caminho entre essas duas pontas, mas é consenso que a inovação é uma propulsora do crescimento econômico, de tal maneira que o antigo Ministério de Ciência e Tecnologia passou a se chamar Ministério de Ciência, Tecnologia e Inovação.

Agregar essa palavra, no entanto, talvez tenha sido apenas simbólica no órgão, que busca “geração de conhecimento e de novas tecnologias, bem como a criação de produtos, processos, gestão e patentes nacionais”, como está apresentado em seu site (BRASIL, 2014). A inovação está implicitamente aí definida como resultado de novas tecnologias.

Voltando aos projetos, um dos primeiros tratamentos se deu em 1697, com o livro “An Essay on Projects”, de Daniel Defoe (CLELAND, 2004). Mas é só a partir do século XIX que o tratamento formal dos projetos e da administração começam a se consolidar com o cientista Frederick Taylor (1856-1915), que é considerado o pai da ciência da administração (SISK, 2010). Taylor estuda a forma como se dá o processo do trabalho e demonstra que a produtividade pode ser aumentada se o trabalho for dividido em atividades e tarefas bem definidas (FACCIONI FILHO, 2011). Essa contribuição à administração e à forma de gerenciamento contribuiu radicalmente para a evolução da indústria.

Henry Gantt, engenheiro mecânico que foi assistente de Taylor, criou uma forma gráfica para organizar as atividades e tarefas de um determinado trabalho, ordenando-os em períodos de tempo e numa sequência lógica de produção. Esse gráfico de barras ficou conhecido como Gráfico de Gantt e é utilizado com muito sucesso em diversos projetos, de todos os tipos (ver ilustração na Figura 1.1).

FACCIONI FILHO, Mauro. Gestão de projetos de inovação: livro digital. Palhoça : UnisulVirtual, 2016.

8


Figura 1.1 – Exemplo de gráfico de Gantt

Fonte: Faccioni Filho, 2011.

Outro importante passo na evolução prática e teórica na gestão de projetos se deu nos Estados Unidos, com a criação, em 1954, pelo IEEE - Institute of Electrical and Electronic Engineers – da revista Transactions on Engineering Management, cujo foco é o de fundamentar e divulgar pesquisas relacionadas à gerência de projetos e produção em engenharia. Praticamente ao mesmo tempo em que a revista foi criada, a empresa Du Pont desenvolveu o “Método do Caminho Crítico”, ou CPM (Critical Path Method), que depois foi unificado com o método PERT (Program Evaluation and Review Technique), criado a partir das experiências da marinha americana no desenvolvimento do projeto do submarino atômico Polaris (FACCIONI FILHO, 2011). Veremos esses métodos com mais detalhes no decorrer deste livro.

Todos os métodos foram desenvolvidos com a intenção de melhorar a qualidade do desenvolvimento dos projetos, com ênfase nos seus prazos e custos. No entanto, algo não tem dado muito certo, como está representado no Quadro 1.1. Depois de décadas de estudos e melhorias nas metodologias de gestão, os projetos continuam com os velhos problemas, e esses problemas inclusive cresceram (FACCIONI FILHO, 2011). O que pode estar acontecendo de errado? São as metodologias que não estão adequadas? São os gestores que não conseguem usar tais ferramentas? Ou há algo ainda não resolvido nessa questão?

Quadro 1.1 – Desvios e problemas na gestão de projetos

Projetos nos EUA

Década de 1950 Década de 1990

Tempo além do previsto ~ 50% até 200%

Custo além do previsto ~100% até 190%

Cancelados antes da conclusão (não disponível) 30%

Fonte: Elaborado pelo autor, 2016.

Como os problemas continuam, continua a busca por soluções. No ano de 1969 foi criado o PMI, Project Management Institute, associação que reúne atualmente mais de 650 mil membros. Esse instituto lançou, na década de 1990, um guia de melhores práticas, o PMBOK, tentando atacar o velho problema da gestão de projetos e superar essas questões que colocamos acima. Não se sabe ainda o resultado prático na gestão de projetos, mas sabemos que milhares de certificações, publicações e treinamentos foram e continuam sendo vendidos mundo afora.

9


A chegada da era da computação também trouxe a sua contribuição, com o lançamento de inúmeras ferramentas para auxílio na gestão dos projetos, algumas que criam automaticamente gráficos e diagramas, bem como softwares que fazem promessas mágicas de melhoria nos projetos. Além da qualidade dos gráficos e dos relatórios, não se sabe ainda o quanto essas ferramentas repercutem nos resultados dos projetos, em termos de ganho de prazo e de custos.

Parece-nos que, em tudo isso, há alguns problemas de fundo não bem resolvidos. Seria importante, então, começar dos pontos mais básicos.

Qual a definição de projeto?

Projeto tem começo, meio e fim. Parte de um demanda pré-definida, sendo que, para chegar ao resultado é necessário arranjar sequencialmente um conjunto de atividades, visando àquela finalidade. Importante pontuar que empreendimentos de rotina não são projetos.

E a inovação?

A inovação está associada a fazer algo novo ou de uma nova maneira. É cultural, não podendo ser determinada por um processo ou sistema. Na conjuntura atual, reflete em grande parte as novidades relacionadas à tecnologia, e criam vantagens competitivas no médio e longo prazo.

O que é gestão?

A gestão se relaciona à ideia de controle, de administração. A gestão de projetos, de acordo com Page-Jones (1990) está associada a cinco atividades:

1. Planejamento do projeto,

2. Organização dos recursos,

3. Integração dos elementos durante a execução do projeto,

4. Medição contínua do andamento das atividades,

5. Revisão regular do plano inicial, até chegar ao objetivo do projeto.

Como se dá a gestão de projetos?

A gestão do projeto se dá pela aplicação e da integração dos seguintes processos: iniciação do projeto, planejamento, execução, monitoramento contínuo, controle e encerramento. Para gerenciar um projeto é preciso:

• Identificar as reais necessidades do projeto (a demanda);

• Estabelecer objetivos bem definidos;

• Distribuir os recursos para obter qualidade, tempo e custo adequados;

• Adaptar as especificações às expectativas dos diversos integrantes, internos e externos.

Qual o problema do prazo?

Em geral, os projetos erram no prazo, de forma que o tempo que estava destinado a realizar o projeto nunca parece suficiente. Acontece que o prazo é o tempo disponível para se chegar ao resultado. Um projeto que não é finalizado no prazo pode não ter nenhum sentido.

10


Quais são os recursos?

São todas as condições materiais, humanas, econômicas, assim como equipamentos, conhecimentos e outros elementos necessários para desenvolver o projeto.

Quanto custa?

O custo de um projeto envolve todos os gastos financeiros para prover os recursos, levando o projeto do início ao fim. Se esses recursos extrapolam o previsto, ou se estendem no tempo, os custos explodem.

Quem vai fazer o trabalho?

A equipe do projeto, que é o grupo dedicado a elaborar e realizar o planejamento e as tarefas, se possível num ambiente de cooperação e motivado para o sucesso.

Nascimento do projeto Os projetos nascem dos clientes. O cliente pode ser externo, alguém que demandou um produto ou apresentou uma necessidade; ou ainda interno, quando temos uma demanda dentro da própria empresa. Pode ser um projeto da família. Pode ser um projeto na escola. Mas sempre há a figura do “cliente”, aquele que vai receber o resultado final.

A partir da solicitação de um cliente é preciso entender corretamente qual é o problema a resolver, o resultado esperado. Com isso, teremos o nascimento do projeto. O diagrama do nascimento do projeto está ilustrado na Figura 1.2 (FACCIONI FILHO, 2011). O ponto de partida está em um problema bem definido e delineado, num defeito a corrigir de um determinado produto ou processo, ou ainda no desejo de um novo produto ou processo. Com essas premissas temos um conjunto de informações iniciais, os dados coletados para dar o início de um futuro projeto. A partir desse conjunto de informações pode-se começar a esboçar o projeto, construir um primeiro desenho ou modelo.

O conceito do design thinking é bastante aderente a esse momento do nascimento do projeto, quando outras informações podem ser trazidas para o escopo do projeto, enriquecendo e aprimorando o modelo. Também nesse processo de modelar, desenhar, imaginar um projeto, está a fase de lançamento de hipóteses de soluções, ideias para se resolver o problema inicial e transformá-lo num projeto real. Com essas bases pode-se, então, traçar com precisão os objetivos almejados, iniciando o projeto propriamente dito.

Figura 1.2 - Diagrama do nascimento do projeto

Problema definido

Defeito a eliminar

Novo produto

Dados coletados

Desenho diagrama

ou modeloHipóteses de solução

Objetivos do projeto

Outras informações

ou

ou


11


Algumas das fontes de novos projetos são as demandas que surgem nas pesquisas e descobertas científicas. Muitas das inovações tecnológicas dos últimos tempos surgiram nos laboratórios e nas universidades. Nesses casos, temos três fontes de novos projetos: as descobertas, as invenções e as inovações propriamente ditas.

Veja a Figura 1.3, que distribui essas fontes numa sequência típica de evolução a partir das pesquisas e desenvolvimentos de base acadêmica e científica, responsáveis pelas maiores inovações comerciais que temos tido nas últimas décadas, com especial interesse na computação, internet e aplicações que daí derivaram.

Figura 1.3 - Diagrama do nascimento do projeto

Descoberta

Corresponde à pesquisa científica,

busca a verdade e a compreens`ao dos

fenômenos da natureza.

Invenção

Corresponde à pesquisa aplicada,

busca um novo produto e uma

racionalidade técnica.

Inovação

Intenção de novas tecnologias, mas com

uma racionalidade econômica.


A descoberta, a invenção e a inovação estão intimamente relacionadas. Basicamente:

• a descoberta corresponde ao resultado de um projeto de pesquisa científica, em geral, não se associa a demandas comerciais;

• a invenção se aproxima da realidade comercial, mas sem a certeza de que terá realmente um mercado;

• a inovação já está bem mais focada no mercado, numa visão que se aproxima da demanda dos clientes, das pesquisas de mercado.

A descoberta tem um viés de distância com o mercado, estando relacionada à pesquisa pura. Seus resultados podem demorar a atender ao mercado ou a aplicações úteis. Isso não lhe tira o mérito, mas às vezes a pressa por produtos vendáveis prejudica a pesquisa voltada às descobertas.

A invenção está associada à pesquisa aplicada. Um indicador prático relacionado aos resultados das invenções é o número de patentes de um determinado grupo ou país.

A inovação vem a seguir, e depende dessa cultura de criatividade, pesquisa e desenvolvimento, com um olhar para a produção de bens ou serviços úteis.

Inovação incrementalPodemos dividir as inovações em dois tipos: incrementais e disruptivas. Não necessariamente essa classificação depende de interesses comerciais, científicos ou industriais, e nem mesmo de graus de dificuldade.

12


Basicamente, a inovação incremental diz respeito a alguma alteração que acrescenta modificação ou melhoria de destaque, seja num produto ou num processo. É o tipo de inovação mais comum, pois parte de algo conhecido e que, após uma modificação (inovação incremental), adquire maior capacidade de venda ou de aceitação no mercado.

As inovações incrementais estão presentes nos projetos de empresas comerciais, que nascem dentro dessas empresas buscando diferencial competitivo no mercado. Lançamentos de novas embalagens, novas versões de software e novas formas de entrega são exemplos desse tipo.

Estão presentes nos projetos industriais, também buscando diferencial competitivo, mas com principal foco no processo produtivo, como mudanças em projetos, peças, introdução de automatismos em máquinas e diversas inovações em processos.

Um modelo de análise dos tipos de projeto e suas inovações foi desenvolvido por Dov Dvir e outros autores (2004), que se baseia em três eixos: o da incerteza do projeto, o da complexidade e o do prazo. O modelo foi denominado pelos autores de Modelo UCP (Uncertainty, Complexity, Pace). Usando esse modelo, podemos distinguir ou caracterizar cada projeto em relação ao seu grau de inovação.

A Figura 1.4 ilustra os três eixos e o posicionamento relativo de um determinado projeto. As Figuras 1.5, 1.6 e 1.7 detalham cada um dos eixos e seus critérios de classificação.

Figura 1.4 - Modelo UCP - Uncertainty, Complexity, Pace

Complexidade

Incerteza

Prazos

Posição relativa do objeto

Fonte: Adaptado de DVIR et al., 2004.

O eixo da incerteza divide os projetos em quatro níveis de tecnologia associada: baixa, média, alta ou super alta tecnologia. Projetos de baixa tecnologia são aqueles em que não há nenhum desenvolvimento ou conhecimento adicional, a não ser os já disponíveis, tal como acontece nos projetos de construção civil, por exemplo. No outro extremo estão os projetos de super alta tecnologia, em que as tecnologias empregadas são totalmente novas ou em desenvolvimento, o que atribui um alto grau de incerteza ao sucesso do projeto.

13


Figura 1.5 - Modelo UCP – eixo das incertezas

Tecnologia

Baixa Média Alta Super Alta

IncertezaFonte: Adaptado de DVIR et al., 2004.

O eixo da complexidade diz respeito à complexidade das inter-relações entre os diversos componentes do projeto. Está dividido em três níveis: o da montagem, o dos sistemas e o dos super sistemas (ver Figura 1.6). Um projeto classificado no nível da montagem significa que seus componentes têm uma estrutura de arranjo simples, de conhecimento dominado, e cujas relações internas são bem dominadas e sem riscos. No extremo oposto, super sistemas implicam relações internas de dispositivos, processos e sistemas diversos, com tecnologias pouco ou não testadas em conjunto, implicando alto grau de complexidade e dependência entre seus componentes.

Figura 1.6 - Modelo UCP – eixo da complexidade

Complexidade

Super-sistemas

Sistemas

Montagem


O eixo dos prazos divide os projetos quanto ao tempo disponível para sua realização. Há três níveis de prazos: os regulares, os competitivos e os críticos (ver Figura 1.7). Os projetos do primeiro nível, ou de prazos regulares, são aqueles em que há um prazo pré-definido, mas com um alto grau de tolerância para atrasos ou modificações de agenda. Já os críticos são aqueles em que o atraso implica o fracasso total do projeto.

14


Figura 1.7 - Modelo UCP – eixo dos prazos

Prazos

Regulares

Competitivos

Críticos


Os projetos de inovação podem ser classificados conforme sua posição relativa no modelo UCP. Projetos de inovação incremental ocupam os níveis inferiores de cada eixo. Conforme o grau de inovação do projeto aumenta, ou seja, conforme a complexidade é maior ou mais alta é a tecnologia associada e ele, mais próximo o projeto estará de uma inovação realmente radical, também chamada de inovação disruptiva.

Inovação disruptiva ou radical e a “killer application”A inovação radical, como vimos acima, está no topo dos eixos do modelo UCP. É a inovação de alto impacto tecnológico e que rompe com uma forma anterior de consumo ou de uso, por isso também é chamada de disruptiva. Pode modificar hábitos de consumidores e alterar a finalidade da tecnologia anteriormente usada.

Esse tipo de inovação é rara, ou pouco comum, porque sua geração é de risco e os empreendedores não sabem se terá sucesso. Na terminologia de mercado surgiu também a denominação “killer application”, aquele produto que é tão inovador, radical, chamativo, que é um objeto de desejo e tem imenso apelo comercial. Sempre associado à inovação, apresenta um caráter disruptivo em relação ao que existia antes.

Um exemplo típico é o telefone celular iPhone, da Apple, que surgiu para vender milhões e praticamente reconstruiu a indústria da telefonia celular. A Apple tem outros exemplos de inovações radicais, que mudaram a indústria. A Ford teve seu momento, há um século, quando lançou o Ford Model T, que revolucionou a indústria automobilística. Podemos pensar em vários outros exemplos: o compact disc, o microcomputador, a internet etc.

Mas o que determina o sucesso de um produto de inovação, e especialmente o de inovação radical?

Nem tudo é possível prever, mas alguns fatores são evidentes:

• Demanda social pelo produto, atual ou potencial;

• Condições financeiras do público para adquirir o produto;

• Estratégia para disponibilizar o produto no mercado e realizar o pós-venda;

• Capacidade técnica, produtiva e comercial de desenvolvimento do produto;

• Compatibilidade com os critérios de usabilidade dos consumidores e capacidade de manter avanços contínuos.

15


Ciclo de vida do projeto

Um conceito importante e que não pode ser deixado de lado é o do ciclo de vida do projeto. No começo deste capítulo, vimos que projeto tem começo, meio e fim, e que empreendimentos de rotina não são projetos. Assim, o ciclo de vida do projeto é o conjunto de fases do andamento do projeto, desde o início até seu encerramento. Dividimos o ciclo de vida do projeto em fase inicial, fase intermediária e fase de finalização, como ilustrado na Figura 1.8.

• Na fase inicial estão a ideia do projeto, a organização da equipe de gerenciamento e de trabalho, uma descrição do escopo e os primeiros documentos relacionados ao planejamento da execução;

• A fase intermediária é aquela em que ocorre boa parte da realização do projeto em si, quando acontece o planejamento, a divisão de tarefas, o gerenciamento contínuo, o controle de entregas parciais e a aceitação de etapas e atividades que compõem o projeto;

• Por fim, há a aceitação do resultado do projeto, na fase de finalização, em que é reunida toda a documentação, os relatórios de análise, aceitação e aprovação do produto resultante, com a efetiva entrega do projeto.

Figura 1.8 – Ciclo de vida do projeto

Idéia Formação da equipe do projeto

Gerenciamento e controles

Entrega do projeto

Escopo Inicial Planejamento

Aprovação e documentaçãoDesenvolvimento

Início Fase Intermediária Finalização

Fonte: Elaboração do autor, 2016.

Resta, enfim, uma pergunta:

O ciclo de vida padrão em projetos é válido para projetos de inovação?

Em princípio, sim. Mas a prática nos mostra que a inovação, especialmente a disruptiva, não se encaixa muito bem nos padrões de gestão convencionais. Ideias novas podem surgir a qualquer momento, em qualquer fase do projeto, e não podem ser deixadas de lado. Isso nos mostra uma necessidade de atuação de gestão muito diferente da convencional, ou seja, aceitar ideias “fora da caixa” deve ser inerente ao processo.

Aceitar tais ideias, integrar ao contexto do projeto, reavaliar padrões e planejamentos, reorganizar equipes, reavaliar o mercado e ouvir conselhos externos são dimensões não usuais em gestão de projetos, e podem determinar as chances de sucesso ou fracasso da inovação.

Capítulo 2

Quem consegue conduzir um projeto de inovação?

Boa parte dos problemas de atrasos e altos custos dos projetos é atribuída a uma gestão ruim. Tanto é assim que os métodos de gestão de projetos estão voltados a gerentes, com treinamentos e certificações diversos, procurando melhorar a gestão.

Mesmo assim, temos visto que nas últimas décadas pouco progresso houve, se considerarmos as pesquisas e estatísticas. Se pensarmos em projetos de inovação, os problemas podem ser ainda maiores. Quem, afinal, deve conduzir tais projetos? Que tipo de gestor é apropriado para a inovação, e com que modelo de equipe de trabalho?

Gestor como “chefe”Em geral, os gestores de projetos se dividem em dois tipos: os gerentes do tipo “chefe” e os “líderes”. A quantidade dos primeiros, também chamados simplesmente de “gerentes”, é desproporcionalmente maior do que dos segundos.

As qualidades de um gerente típico de projeto, de acordo com a literatura (PAGE-JONES, 1990), são as seguintes:

• integridade pessoal,

• sensibilidade para as demandas da equipe,

• capacidade de estabelecer objetivos razoáveis e executáveis,

• capacidade de cumprir objetivos, com persistência,

• capacidade de estimular a equipe,

• disposição de ajudar os membros da equipe,

• competência técnica (e com isso assegurar a confiança de sua equipe),

• capacidade de delegar atividades (e não centralizar),

• capacidade de tomar decisões,

• habilidade para se comunicar.

Outra fonte considera que as características de um gerente se dividem em três áreas: quando aos seus conhecimentos, quanto às suas habilidades e quanto às suas atitudes (VALERIANO, 1998). Certamente, nem todo gestor consegue reunir todas essas características. O Quadro 2.1 enumera algumas das características principais, distribuídas nessas três áreas.


17


Quadro 2.1 – Características dos gerentes de projetos

Características dos gerentes de projetos

Conhecimentos Habilidades Atitudes

Sistema administrativo e financeiro da organização

Planejamento, organização e controle das atividades do projeto.

Interesse e posicionamento nas questões administrativas empresariais

Sistema de RH e suas relações jurídicas

Capacidade de liderança e trabalho em equipe

Disciplina de trabalho e dedicação produtiva diária

Práticas, políticas e valores da organização

Capacidade de autoanálise e autocrítica

Entrosamento com pessoal externo à organização

Consciência do custo e das implicações das decisões técnicas

Capacidade de alocação balanceada de recursos

Ambição profissional

Conhecimento profundo das atividades econômicas da organização.

Capacidade de gerar confiança no superior, com trabalho orientado a resultados.

Visão geral do problema e do ambiente de negócios em que o projeto está envolvido

Conhecimento das áreas correlatas à especialização.

Perceber e escolher o estilo de liderança adequado ao trabalho

Leitura sistemática de textos técnicos e atualização constante em relação às inovações tecnológicas

Competência técnica em pelo menos uma área de especialização

Tomada de decisões, condição essencial numa função de comando

Domínio de métodos de pesquisa Criatividade na solução de problemas

Capacidade de se comunicar e de se relacionar


Em relação aos conhecimentos que um gerente de projeto deve ter, não nos referimos aos conhecimentos técnicos para desenvolver o projeto em si, mas a uma série de conhecimentos gerais e estratégicos, que em conjunto permitirão uma boa administração do trabalho.

Um gestor precisa conhecer algo da área administrativa, financeira e de recursos humanos da organização, assim como algumas das principais questões jurídicas associadas a recursos humanos, em especial no Brasil, onde as leis trabalhistas muitas vezes prejudicam o andamento de projetos comuns, e ainda mais os de inovação.

O gestor precisa ter um bom controle da parte de custos e de como suas decisões técnicas podem impactar nos custos do projeto.

Do ponto de vista técnico, o gestor não precisa, certamente, conhecer todas as competências associadas ao projeto, porém deve dominar profundamente ao menos uma das especializações envolvidas, bem como ter um conhecimento genérico das outras especialidades, com domínio de metodologias de pesquisa. Isso o aproximará da equipe.

18


Em termos de habilidades, o gestor deve ter evidente capacidade de planejar, organizar e controlar as atividades e todas as tarefas envolvidas no projeto. Isso envolve habilidades de liderança (mesmo não sendo um típico “líder”), de autocrítica, de distribuição de atividades de forma equilibrada, gerando confiança para os que atuam com ele. Isso se associa a uma capacidade de comunicação, que deve ser inata ou desenvolvida, pois é habilidade essencial na atividade de gestão, que deve ser exercida com a capacidade de criar soluções e de decidir, habilidades certamente cobradas por quaisquer grupos de trabalho.

As atitudes estão relacionadas ao dia a dia do gestor e se constituem em algo bem visível por todos da equipe. Incluem itens como o seu entrosamento com as pessoas da equipe e de fora dela, sua disciplina, dedicação, interesse geral e específico, ambição pelos resultados e pela qualidade do projeto, estudo contínuo e demonstração de visão geral dos problemas internos ao projeto e também fora dele.

Essa composição de características tende a uma idealização. Porém, são itens que podem ser inatos, mas também podem ser trabalhados, desenvolvidos. Um problema diferente é o da liderança, algo mais difícil de alcançar, por muitas vezes ser uma característica inata.

Gestor como “líder”Há muitos problemas que fazem os projetos atrasarem ou extrapolarem nos custos. Escopos mal descritos ou incompletos, mudanças constantes dos requisitos dos clientes, planejamentos mal elaborados, entre muitos outros. Mas provavelmente um dos grandes problemas é o da gestão.

Ao abordar projetos de inovação, associados muitas vezes ao empreendedorismo, a gestão passa a ser ainda mais crítica, e nesses casos surge a figura da liderança como mais forte do que a da simples “gerência”. Talvez, nesses casos, o fator principal para o sucesso de um projeto seja a atitude da liderança.

No artigo “Understanding the role of ‘vision’ in project success” (CHRISTENSONM; WALTER, 2004), em que se analisa o papel da “visão” para o sucesso de um projeto, é sugerida uma divisão em quatro tipos de liderança:

1. Líder que considera os indivíduos da equipe, que é capaz de estimular as pessoas numa visão nova de seu próprio trabalho;

2. Líder que estimula intelectualmente o seu grupo, gerando um alinhamento positivo das ideias em relação à organização e ao projeto;

3. Líder que influencia os ideais, estimulando o grupo de trabalho a alcançar altos níveis de habilidade;

4. Líder que motiva inspirações, levando cada um a olhar além do interesse individual e em direção ao benefício de todo o grupo.

Certamente não é possível diferenciar totalmente o líder do gestor, como se fossem indivíduos distintos. Os dois papéis estão presentes em cada pessoa, em maior ou menor grau. As atividades com as quais se está envolvido podem estimular cada papel, sendo que nos projetos de inovação a figura do líder tem maior grau de importância.

19


O Quadro 2.2 apresenta um conjunto de distinções entre líderes e gerentes no decorrer de um projeto. Poderíamos dizer que as atitudes do líder são mais relevantes nos projetos de inovação, enquanto as do gerente são relevantes nos projetos convencionais.

Quadro 2.2 – Distinções entre gerentes e líderes de projetos.

GERENTE LÍDER

O que busca? Um resultado dentro do esperado Um nível superior e inesperado

O que quer? Substituir Transformar

O que pretende? Fazer certo as coisas Fazer a coisa certa

Seus fundamentos? Métodos Propósitos

Como gosta de atuar? Trabalhar dentro do programado No planejamento e programação

Como responde aos problemas? Baseado na rapidez Baseado numa direção

Como resolve os problemas? Por medições e indicadores Pela reflexão

Base dos resultados? Na eficiência Na eficácia

Núcleo do poder e das decisões?

As utilidades Os princípios

O que são gastos? Despesas Investimentos

Forma de trabalho? Dentro da base estrutural Com espontaneidade

Ideias? Controla, dentro das atividades Deixa livres e fortalece

Tipo de interesse? Nas coisas do projeto Nas pessoas do projeto


Ao analisar o Quadro 2.2 podemos ver que a gestão com as características do gerente são bem mais formais e adaptadas para projetos regulares, em que os resultados são razoavelmente bem definidos. Por esse motivo, o gerente pretende, com o novo projeto, substituir resultados de projetos anteriores, de maneira correta e por meio de métodos bem determinados. Nesses casos, as certificações e cursos de gestão são válidos devido a seu foco em métodos e sua programação bem estabelecida, em que o tempo de resposta seja curto no projeto. O sistema de controle se dá por indicadores claros, em que todos na equipe precisam atuar com eficiência, baixos custos, focados nos “objetos” esperados como resultados.

Já o líder atua de maneira um tanto distinta, que o aproxima dos projetos de inovação em que algo surpreendente é esperado. Por esse motivo, sua busca é por transformação das coisas, com base em propósitos e visões, em que o líder planeja constantemente os próximos passos de acordo com seus princípios norteadores. A solução de problemas se dá por reflexão a partir desses princípios, em que um alto grau de espontaneidade e liberdade é admitida como inerente ao projeto, sendo que os gastos financeiros são vistos como investimentos, não como custos. O líder acaba valorizando muito mais as pessoas e as ideias do que os métodos e os resultados imediatos do projeto, e isso acaba por tipificar as inovações, com seus fracassos e sucessos.

No processo de valorização das pessoas em inovação passa a ser fundamental analisar como as equipes de trabalho são montadas, e como atuam no dia a dia do projeto.

20


Equipes de projeto de inovaçãoAs equipes de projeto basicamente se organizam em cinco tipos de estruturas: exclusivas, híbridas, matriciais, modulares e horizontais (FACCIONI, 2011). Esses modelos são os que a prática de projetos acabou definindo no decorrer do tempo, e ao desenharmos tais estruturas podemos perceber como se organizam no trabalho, além dos tipos de projetos mais adequados para cada um.

Cada estrutura também estabelece o modelo de gestão aplicável, e se está mais próxima de um projeto convencional ou de um projeto de inovação.

Estruturas exclusivas

As estruturas chamadas de exclusivas são aquelas voltadas a projetos de pequeno porte, capazes de ter pessoal e recursos exclusivos ao projeto. A equipe se dedica exclusivamente ao projeto, com pequena complexidade organizacional, formando estruturas simples e funcionais.

A estrutura exclusiva, representada na Figura 2.1, indica que seus membros são dedicados apenas ao projeto em questão, sendo que os processos internos são simples, diretos, de fácil compreensão para todos os envolvidos. Por ser de simples organização, é fácil para um líder atuar com comunicação rápida e baixa burocracia processual, o que favorece projetos de todos os tipos, em especial os de inovação, que exigem alto grau de agilidade. Um exemplo desse tipo de estrutura foi aplicado por Steve Jobs no desenvolvimento do primeiro computador Macintosh, da Apple, em que um pequeno grupo de técnicos se dedicou exclusivamente ao projeto, interagindo diretamente com o gestor principal. É uma estrutura bastante favorável aos projetos de inovação.

Figura 2.1 – Equipe de projeto com estrutura do tipo exclusiva

Membro TÉCNICO 1 Membro TÉCNICO 3

Apoio administrativo

Cliente

/proprietário do projeto

Gestor

/líder do projeto

Membro TÉCNICO 2


21


Estruturas híbridas

As estruturas híbridas partem do modelo das estruturas exclusivas, mas ocorrem em empresas maiores, quando há participantes do projeto que não podem estar dedicados exclusivamente a ele. Projetos maiores contam com um conjunto de especialistas dedicados, e algumas funções são preenchidas por pessoas que fazem parte de outros departamentos, dedicando-se parcialmente ao projeto em questão, ou mesmo a vários projetos. Pode-se pensar, por exemplo, em pessoas da área financeira, que coordenam o fluxo de caixa de vários projetos simultaneamente, ou técnicos de maquetes, desenhistas avulsas etc, que colaboram em vários trabalhos.

A Figura 2.2 apresenta o organograma típico desse modelo de estrutura, em que o gestor do projeto conta com membros dedicados exclusivamente, mas recorre também a outras pessoas, importantes para o projeto, mas que se dedicam a outras áreas da empresa.

O sucesso do projeto depende da liberdade de trabalho do gestor para recrutar as pessoas da empresa, e como poderá trabalhar com esse grupo. Projetos de inovação podem se encaixar nessa estrutura, mas a liberdade de atuação do gestor é que definirá o progresso e sucesso da inovação.

Figura 2.2 – Equipe de projeto com estrutura do tipo híbrida

Gerência Geral da empresa

Membro TÉCNICO 1

Membro TÉCNICO n

Gestor /líder do projeto

Área administrativa

Área financeira Engenharia Área

comercial


22


Estruturas matriciais

A estrutura do tipo matricial pode ser considerada uma evolução da estrutura híbrida, quando já não há mais participantes com dedicação exclusiva. Nesse caso, um gestor de projeto tem o controle do projeto, mas compartilha os membros da equipe com diversas outras equipes. Por esse motivo, a estrutura é muito mais complexa e exige um alto grau de organização e processos bem definidos e estruturados. Membros de um projeto participam também em outros projetos, com outros gestores, muitas vezes com outras culturas de atuação.

Nesse caso, também há grande exigência de maturidade da própria empresa, que precisa ter processos maduros, bem delineados e compreendidos por todos, pois os funcionários estarão se deslocando entre grupos e funções diferentes, com perspectivas e prazos diferentes.

A Figura 2.3 ilustra a estrutura matricial, na qual se percebe que vários projetos ocorrem simultaneamente. Pessoas de um departamento podem estar atuando em vários projetos. Cada projeto tem seu gestor, mas até mesmo o gestor pode atuar em dois projetos de pequeno porte, em paralelo. Essa coordenação não é simples, e muita prática e experiência é exigida dos grupos de trabalho.

Em geral, essa estrutura é coerente com projetos convencionais, de baixa inovação, pois o grau de liberdade é limitado, e dificilmente se admitem mudanças de planos ou de prazos.

Figura 2.3 – Equipe de projeto com estrutura do tipo matricial

Gerência Geral da empresa

Área administrativa

Área financeira Engenharia Área

comercialÁrea

técnica 1Área

técnica n

Projeto 1

Projeto 2

Projeto 3

Projeto 4


Estruturas modulares

Diferente das estruturas anteriores, a estrutura modular tem uma concepção baseada em especializações. Grupos especializados em determinados temas atuam dedicados ao módulo de especialidade. Dessa forma, um projeto será dividido em módulos, sendo que cada módulo tem sua demanda específica, que será coberta por determinada especialização.

23


O gestor desse tipo de projeto desloca o trabalho de módulo para módulo, sendo que cada grupo recebe o projeto já num determinado contexto, e então aplica sua especialização para desenvolver mais uma etapa. No interior do grupo a gestão também se dá de modo independente, com suas próprias regras e cultura. O grupo não necessariamente precisa compreender a função final do projeto, apenas as entradas do módulo, e entregar sua parte com determinadas especificações, ou saídas. A partir dali, o gestor levará o projeto para o módulo seguinte, passo a passo, até a conclusão do projeto.

A Figura 2.4 mostra o organograma desse tipo de estrutura, em que o gestor se relaciona com os diversos grupos ou especializações. A capacidade de inovação desse tipo de projeto está bastante vinculada ao perfil do gestor ou líder do projeto. Projetos de software envolvendo grandes equipes com diferentes conhecimentos, por exemplo, podem usar esse tipo de estrutura. Outro exemplo de uso desse tipo de estrutura se dá em projetos de alto grau de segurança e sigilo, como o desenvolvimento de armas ou sistemas antiterror, em que cada módulo atua em parte do projeto, sem se conhecer o resultado final.

Devido à grande separação entre os grupos, esse tipo de estrutura parece apropriada para projetos convencionais, mesmo que com características de alta tecnologia. A inovação fica prejudicada pois não há oportunidades de grandes variações no escopo do projeto durante sua evolução. A ideia pré-definida, no início do projeto, não pode sofrer alterações, sob risco de fracasso devido à gestão e ao controle, que não podem ser alterados.

Figura 2.4 – Equipe de projeto com estrutura do tipo modular


Grupo TÉCNICO 3

Desenvolvimento HARDWARE

Grupo TÉCNICO 4

DESIGNER gráfico

Grupo TÉCNICO 1

Grupo TÉCNICO 2


Estruturas horizontais

Basicamente, as estruturas horizontais são definidas em projetos de menor porte, pois são constituídas por poucos membros com alta especialização e grande nível de relacionamento. Falamos aí de projetos de pesquisa de ponta, por exemplo, em que técnicos especializados interagem diretamente entre si, buscando os resultados que todos compreendem. Nesse tipo de estrutura o gestor funciona como uma espécie de facilitador, agregador, muitas vezes como um líder natural e aceito pelo grupo.

24


Nas estruturas horizontais os membros relacionam-se diretamente, em rede, e isso agiliza a tomada de decisões, a busca por soluções, constituindo-se um espaço onde a inovação tem muita aceitação. O líder do grupo tem a função de acompanhar o andamento das atividades, e muitas vezes é membro ativo do desenvolvimento do projeto, tendo também alto nível de especialização, de tal forma que sua ascendência sobre o grupo seja inequívoca.

A Figura 2.5 ilustra a configuração de uma estrutura horizontal típica, e no exemplo da figura vemos os especialistas interagindo diretamente, sem a necessidade de intervenção do gestor. Projetos e inovação disruptivas nascem de estruturas desse tipo.

Figura 2.5 – Equipe de projeto com Estrutura do tipo Horizontal


DESIGNER gráfico

Especialista TÉCNICO 1

Cliente /contratante

/diretoria



Engenheiro SOFTWARE


Considerando as cinco estruturas apresentadas, e um modelo de gestão baseado em lideranças, podemos perceber que a inovação disruptiva se aproxima do modelo Horizontal, que é bastante dinâmico e especializado. Mas a inovação incremental já se adapta ao modelo do tipo Exclusivo ou mesmo o Modular. O sucesso nesses casos ficará bastante dependente do estilo do gestor. Ferramentas de apoio, ou metodologias de gestão, serão elementos importantes para dar agilidade e organização ao desenvolvimento, como veremos a seguir.

25


ReferênciasCHRISTENSON, Dale; WALKER, Derek H. T. Understanding the role of “vision” in project success. IEEE Engineering Management Review, v. 32, n. 4, p. 57-73, 2004.

FACCIONI FILHO, M. Gestão de Projetos e de Equipes. Palhoça: Unisul Virtual, 2011.

PAGE-JONES, Meillir. Gerenciamento de projetos: guia prático para restauração da qualidade em projetos e sistemas de processamento de dados. São Paulo: McGraw-Hill, 1990.

VALERIANO, Dalton L. Gerência em projetos: pesquisa, desenvolvimento e engenharia. São Paulo: Makron Books, 1998.

Capítulo 3

Os métodos tradicionais de gestão de projetos valem a pena?

Discutimos anteriormente que os projetos, mesmo com todas as novas metodologias de gestão, novas ferramentas e muitas práticas diferentes, não têm conquistado bons resultados em termos de prazos e custos. É difícil avaliar onde estão os erros nesse processo, mas os projetos continuam surgindo e é importante mantermos as pesquisas de novos processos e novas experiências, em especial quando tratamos de projetos e inovação.

Há métodos tradicionais cujo uso vem se mantendo. Será que eles são apropriados? Ou não estão sendo utilizados corretamente? Como funciona o fluxo do projeto e como esses métodos podem ser aplicados?

Podemos entender o fluxo do projeto como uma sequência de passos que nos ajuda a modelá-lo, e que devem ser seguidos para que se chegue ao resultado definido no escopo inicial.

No fluxograma da Figura 3.1 (FACCIONI FILHO, 2011) estão ilustrados todos os passos seguidos por um projeto, desde aquele mais convencional até o de produtos de inovação. Esse fluxograma atende a qualquer tipo de projeto. A partir de cada passo, incluindo as necessidades de reavaliação contínua, podemos ver a ação necessária que caberá ao gestor do projeto. Na sequência, veremos como alguns métodos de acompanhamento e apoio ao gerenciamento poderão ser aplicados. De forma genérica, o fluxo sempre passará por:

• planejamento,

• definição e organização dos recursos,

• acompanhamento da execução,

• verificação e medição dos resultados,

• revisão contínua até a conclusão.


27


Figura 3.1 – Fluxograma do desenvolvimento do projeto

Objetivos do projeto

Encerramento do projeto

Planejamento das atividades

Definição dos recursos

Obtenção dos recursos

Integração dos recursos

Execução das atividades

Revisão do projeto

Acompanhamento e medições

Ferrasmentas de apoio

os objetivos foram alcançados?Não

Sim


Após definidos os objetivos, temos a realização do projeto, conforme o fluxo representado na Figura 3.1, em que os seguintes passos são detalhados:

• Planejamento das atividades – neste momento do projeto são definidos os recursos necessários, as equipes, o detalhamento das atividades, a distribuição de tarefas, os objetivos parciais e os indicadores necessários para poder fazer as verificações passo a passo. O uso de ferramentas de apoio, derivadas das diversas metodologias, é muito interessante nessa fase. Veremos como gráficos de Gantt e outros diagramas de análise prévia do projeto podem clarear, para o gestor e equipe, como se dará o processo e como podemos refinar o planejamento.

• Definição dos recursos – derivando da etapa do planejamento vem a definição dos recursos do projeto, que é algo fundamental para avaliarmos a capacidade da produção. Recursos financeiros insuficientes, falta de pessoal especializado, estimativas erradas de suprimentos etc., podem afetar drasticamente a capacidade de conclusão e sucesso do projeto.

28


• Obtenção dos recursos – muitas vezes, o projeto nasce já com uma alocação de recursos financeiros, de pessoal e materiais. No entanto, a etapa de definição de recursos pode estimar grandezas bem diferentes das inicialmente alocadas, e então é preciso buscar novos recursos. Quando há um cliente com um montante já fechado, será necessário adaptar o projeto àquele recurso, na medida da possibilidade. Mas, quando há muitas discrepâncias, talvez um projeto nem se inicie e o fluxograma pode ser interrompido já neste momento, evitando fracassos logo adiante.

• Integração dos recursos – não só a obtenção dos recursos pode vir a ser um problema, mas também a integração desses recursos quando há diferentes fontes entradas. Grupos de pessoas que não trabalharam juntos, falhas na coordenação de equipamentos e fornecedores, bem como nas adaptações de estrutura física e de processos, são problemas por organizar e integrar já na fase prévia à execução em si, como se verá adiante.

• Execução das atividades – muitos estão acostumados a iniciar um projeto já na fase de execução, o que é um erro. As etapas anteriores descrevem partes fundamentais e decisórias do projeto. A etapa de execução é quando o planejamento e todos os recursos estão definidos e integrados passam a entrar em operação, realizando o projeto. A execução se dará nessa etapa, de acordo com o planejado e seguindo a sequência das tarefas programadas, com suas contínuas revisões e acompanhamentos, até se chegar ao resultado almejado.

• Acompanhamento e medições – colocados no desenho da Figura 3.1 ao lado da etapa da execução, os processos de acompanhamento e medições são fundamentais para o sucesso de um projeto. Consistem do acompanhamento e verificação do andamento do projeto, avaliando periodicamente a concordância entre tarefas programadas e tarefas realizadas. Essa função é da gestão do projeto, e o gestor se faz presente no controle do dia a dia deste. Indicadores de sucesso de cada pequena tarefa devem estar presentes e são verificados constantemente, e com isso é possível corrigir desvios, tomar decisões, alterar planejamento e avaliar as condições e riscos do projeto. Ferramentas de planejamento são muito úteis, pois permitem manter a avaliação e seus registros, sendo que algumas ferramentas podem, inclusive, apresentar linhas de tendências e outras análises.

• Revisão do projeto – também em paralelo ao acompanhamento e medições há uma atividade específica, a revisão. Essa revisão pode acontecer no final de um pequeno projeto ou fazer parte de um processo de revisões contínuas, por etapas, o que acontece em projetos de maior porte. No acompanhamento, há a verificação de adequação do projeto (ou etapa) ao que estava programado. Se for percebido que o objetivo não foi alcançado, uma revisão pode ser feita para criar então um novo planejamento e buscar, assim, um objetivo coerente com as possibilidades ou expectativas do projeto. A Figura 3.2 mostra o ciclo de revisão quando realizado a cada etapa. Esse tipo de revisão intervalada do projeto, apesar de criar pequenas “paradas” de avaliação, pode ser muito útil no sucesso geral do projeto, e com certeza é válido na inovação, em que o grau de incerteza é alto e exige reavaliações e tomadas de decisão a todo o momento.

29


• Encerramento do projeto – a conclusão do projeto acontece quando os objetivos são alcançados inteiramente ou parcialmente, de acordo com os critérios estabelecidos para aceitação. Não basta haver a conclusão do produto ou da solução para que haja o encerramento, pois essa etapa é bem definida e compreende, além da conclusão do resultado esperado, também a documentação pertinente, a comunicação às partes interessadas, o treinamento quando necessário, a instrumentação e os acabamentos além da realização da passagem do resultado ao cliente ou solicitante.

Figura 3.2 – Fluxograma da fase de revisão

Replanejamento

Revisão da etapa

Próxima etapa

Os sub-objetivos foram alcançados?

SIM

NÃO


Várias ferramentas e metodologias têm sido desenvolvidas ao longo do tempo para apoiar os gestores no seu planejamento e acompanhamento. Tais métodos foram desenvolvidos considerando projetos convencionais, porém, alguns modelos cabem no desenvolvimento da inovação, mas isso depende muito do tipo de estrutura de equipe e do modelo da liderança. Vamos discutir sobre algumas dessas metodologias e verificar se, de fato, “valem a pena”.

Modelo de Gantt

O modelo de Gantt, conhecido como Gráfico de Gantt, é um modelo que se baseia em um gráfico de barras horizontais. Foi desenvolvido pelo engenheiro Henry L. Gantt (1861-1919) (FACCIONI FILHO, 2011) para gestão de atividades num ambiente industrial. Gantt trabalhou na equipe de Taylor, que tentava formular vários modelos para a administração empresarial e industrial.

O modelo desenvolvido por Gantt procurou dividir as diversas tarefas de produção industrial em períodos de tempo. Num gráfico de barras, atribuiu a cada tarefa uma barra de comprimento igual ao do período estimado para sua execução. A Figura 3.3 ilustra um modelo simples de gráfico de barras, em que as tarefas têm diferentes períodos de execução. Essa visão gráfica facilita a todos os envolvidos perceber o “tamanho” da tarefa em termos de tempo de execução, pois cada integrante de equipe, vinculado a determinada tarefa, compreenderá facilmente o prazo de seu trabalho e poderá acompanhar o progresso.

30


Figura 3.3 – Gráfico de barras - Gantt

Tarefa 1

Tarefa 2

Tarefa 3

Tarefa 4

1 2 3 4 5 6

Tempo (dias)


No entanto, o gráfico de barras simples, apesar de útil, não traz algumas informações importantes em projetos. A programação das tarefas numa sequência lógica deve permitir desenhar essas barras na mesma sequência em que deverão acontecer. E se cada tarefa tem uma determinada data para começar, a barra deverá iniciar nessa data. Com isso, o gráfico é aprimorado e, além de perceber cada tarefa em sua dimensão, permite ver quando a tarefa deverá ser iniciada, quais as tarefas anteriores e as posteriores, até a finalização do projeto, como ilustrado na Figura 3.4.

Figura 3.4 – Gráfico de barras com tarefas em sequência

Tarefa 1

Tarefa 2

Tarefa 3

Tarefa 4

1 2 3 4 5 6

Tempo (dias)


Dessa forma, o início da barra marca a data de começo da atividade e o final da barra seu término, sendo que a barra se estende por todo o período compreendido entre as duas datas. No exemplo da Figura 3.4, a Tarefa 1 se estende por dois dias, e a Tarefa 3 tem início após a Tarefa 1, e na sequência deve acontecer a Tarefa 4. Percebe-se que a Tarefa 2 é realizada em paralelo com as outras três tarefas, e o projeto todo tem duração de 6 dias. Essa visualização gráfica é o grande trunfo desse método, que é bastante simples e objetivo. É fácil para o gestor e para os integrantes da equipe entenderem a sequência das tarefas e o tempo disponível para cada uma, mesmo em projetos muito grande e com muitas tarefas.

31


O gráfico de Gantt passou, então, por vários aprimoramentos, e um deles é permitir o acompanhamento do projeto no seu dia a dia. A Figura 3.5 ilustra o gráfico com acompanhamento, sendo que para cada tarefa uma segunda barra é desenhada diariamente. A barra principal (cinza) é a do planejamento, e a barra logo abaixo (vermelha) é preenchida constantemente, conforme o projeto avança. Com isso, pode-se verificar rapidamente se cada tarefa foi cumprida no prazo previsto, e também os eventuais atrasos. No exemplo dessa figura nota-se que a Tarefa 1 estendeu-se por um dia a mais do que o previsto, o que levou a Tarefa 3 um dia adiante. Já a Tarefa 4, que devia começar logo após a Tarefa 3, teve um atraso em seu início, e ainda está no começo, já com atraso acumulado de dois dias (a Tarefa não está finalizada). A Tarefa 2 foi cumprida no tempo programado, de quatro dias, porém, teve começo e final defasados em relação ao programado. Como essa tarefa não é determinante no prazo total do projeto, não houve prejuízo.

Figura 3.5 – Gráfico de barras com acompanhamento

Tarefa 1

Tarefa 2

Tarefa 3

Tarefa 4

1 2 3 4 5 6

Tempo (dias)


Os exemplos das Figuras 3.3 a 3.5 são apenas ilustrações do método, pois a formatação do gráfico tem muitas variações, conforme cada ferramenta ou design. Mas essencialmente não há variações, e mesmo com planilhas simples um gráfico desses pode ser construído. Seu objetivo é criar uma visão ao mesmo tempo geral do projeto, com o ordenamento de todas as atividades, e incluir informações mais detalhadas de cada tarefa, como prazo e acompanhamento, permitindo a todos os integrantes da equipe e outras partes interessadas uma visão rápida do trabalho.

Projetos muito grandes, com grande variedade de tarefas, podem criar divisões por grupos de atividade ou por módulo. Isso se encaixa numa estrutura de equipe modular, por exemplo. Numa visão geral, as barras inicialmente apresentam apenas as macroatividades, ou módulos, para que se tenha um apanhado geral do projeto. Depois, para cada macroatividade há um gráfico de Gantt específico, em que as atividades são divididas em tarefas. Integrantes da equipe de um determinado módulo passam a prestar atenção apenas àquele gráfico em que estão trabalhando. O gestor geral do projeto simplifica seu controle, de tal forma que pode se ocupar apenas da relação entre módulos.

32


O custo do projeto não está presente no gráfico de Gantt, e isso poderia ser uma desvantagem. Para ultrapassar esse problema, são feitos cronogramas físico-financeiros, que relacionam as atividades com os valores estimados por atividade, que passam a ser acompanhados no dia a dia. Uma opção simples que as ferramentas computacionais podem trabalhar na interface visual do gráfico é apresentar valores junto com as barras, além dos gastos já realizados na barra de controle. Apesar da simplicidade, é útil para visualizar o andamento do projeto, como se pode perceber na Figura 3.6. No exemplo, vemos que o projeto deveria ter um custo total de $ 2.100, porém, ainda não está concluído e já foram dispendidos $ 2.300, o que demonstra um estouro no orçamento (além do prazo).

Figura 3.6 – Exemplo de gráfico de barras com acompanhamento de custos

1000

400

100

600

Tarefa 1

Tarefa 2

Tarefa 3

Tarefa 4

1 2 3 4 5 6

Tempo (dias)

1500

450

100

250

2100 2300Fonte: Elaborado pelo autor, 2016.

Interdependência das atividades

Um problema presente nos projetos é a interdependência entre as diversas atividades. Há atividades que só podem iniciar quando outra é encerrada, e aquelas que só podem começar simultaneamente ao início de outra, e assim por diante. Isso precisa estar visível no gráfico de barras e as setas de dependência passaram a ser outro grande avanço na metodologia.

Considerando duas atividades, A e B, verificamos que há quatro tipos possíveis de interdependência entre elas:

• Dependência fim-início, quando o início da Atividade B só é possível após o fim da Atividade A (veja Figura 3.7);

• Dependência fim-fim, quando o final da Atividade B deve, necessariamente, coincidir com o fim da Atividade A (veja Figura 3.8);

• Dependência início-início, quando o início da Atividade B deve, necessariamente, coincidir com o início da Atividade A (veja Figura 3.9);

33


• Dependência fim-início com folga, quando o início de uma Atividade B só é possível após o fim da Atividade A, porém, há uma determinada folga de tempo entre as atividades (veja Figura 3.10).

Figura 3.7 – Gráfico de Gantt com seta indicando dependência fim-início

Atividade A

Atividade B


Figura 3.8 – Gráfico de Gantt com seta indicando dependência fim-fim

Atividade A

Atividade B


Figura 3.9 – Gráfico de Gantt com seta indicando dependência início-início

Atividade A

Atividade B


Figura 3.10 – Gráfico de Gantt com seta indicando dependência fim-início com folga

Atividade A

Atividade B

folga


O gráfico de Gantt conquistou uma importante posição no gerenciamento de projetos devido a sua capacidade de entendimento intuitiva. Engenheiros da construção civil utilizam a metodologia diariamente, tanto para o planejamento e acompanhamento dos trabalhos, como também para explicar e comunicar o projeto aos integrantes da equipe e aos clientes. Essa facilidade de visualização autoexplicativa é uma grande vantagem do gráfico. Porém, ele não ajuda na fase de organização das tarefas, que dependem, então, exclusivamente da experiência e cálculos do próprio gestor do projeto. Mas isso não lhe tira o mérito e o método “vale a pena” para projetos de inovação.

34


Outros métodos foram desenvolvidos com a finalidade de calcular e simular a melhor ordem das tarefas, realizar controle, acompanhamento e auxílio na tomada de decisões de projetos, como veremos a seguir.

Por fim, vemos, nas Figuras 3.11 e 3.12, dois exemplos de Gráficos de Gantt gerados por softwares de mercado, sendo o primeiro o de uma ferramenta gratuita chamada jxProject, e a segunda vem do mais popular software de gerenciamento, o MS Project.

Figura 3.11 – Exemplo de Gráfico de Gantt obtido com a ferramentas de software jxProject

Fonte: jxProject, 2012.

Figura 3.12 – Exemplo de Gráfico de Gantt obtido com a ferramentas de software Microsoft Office Project

Fonte: Microsoft Office Project, 2016.

35


Modelo PERT/CPM

O modelo PERT/CPM surgiu nos Estados Unidos após a Segunda Guerra Mundial, como resultado do projeto de desenvolvimento do submarino nuclear Polaris. Por ser um projeto muito grande, com o envolvimento de quase dez mil fornecedores, e devido ao receio de custos exagerados, foi criado um programa para avaliação e revisão constante do projeto, que veio a gerar o método PERT – “Program Evaluation and Review Technique” (PRADO, 1998). O programa foi muito bem sucedido e a partir de então muito utilizado, sendo que posteriormente várias melhorias foram incluídas na técnica, em especial o Método do Caminho Crítico, ou “Critical Path Method”, cujo acrônimo, CPM, veio a se juntar à sigla inicial, dando origem ao que chamamos hoje de PERT/CPM.

A ideia da técnica PERT/CPM é criar um diagrama de setas que verifique todas as atividades e seus pré-requisitos, seus prazos de execução, e qual a sequência de realização das diversas atividades no decorrer do projeto. Com base na análise desse diagrama é possível ver os diversos caminhos de realização das atividades, sejam os que ocorrem encadeados ou em paralelo, e então traçar o “caminho crítico”, ou seja, a sequência de atividades que determinam o tempo total necessário para o projeto. Essa sequência é crítica no sentido de que qualquer alteração nela trará consequências diretas ao prazo e aos custos do projeto.

Entre as várias aplicações das técnicas PERT/CPM, pode-se citar algumas de suas vantagens e capacidades (FACCIONI FILHO, 2011):

• pode apoiar na definição das atividades do projeto já na fase inicial do planejamento;

• durante o planejamento, pode ser útil na definição e detalhamento da duração de cada atividade;

• com base nos prazos de cada atividade, a ferramenta pode ajudar no rearranjo das atividades, quando pertinente, para buscar o prazo mínimo do projeto total;

• permite encontrar as ligações temporais entre as diversas atividades, ou seja, verificar os tempos de folga entre atividades sequenciadas;

• permite identificar as atividades críticas do projeto, ou seja, aquelas cujo prazo determina o andamento de todo o projeto, nas quais a ocorrência de problemas e atrasos retardarão todo o trabalho;

• possibilita determinar a sequência crítica do projeto, considerando as atividades críticas, ou seja, determinar a sequência de atividades críticas que perfazem o “caminho crítico” do projeto;

• permite verificar os tempos de folga existentes entre as atividades, de tal modo que se possa trabalhar com esses prazos durante a execução do projeto sem afetar o prazo total.

O modelo PERT/CPM utiliza setas e nós (círculos) para compor o diagrama, como ilustrado na Figura 3.13 em que cada seta representa uma determinada atividade (atividade A, atividade B, atividade “n”) e os círculos representam um evento ou nó. Cada nó representa a conclusão de uma atividade ou de um conjunto de atividades. A duração de cada uma não está representada pelo comprimento das setas, pois essas não são representadas em escala. A importância das setas é a direção e a sequência no encadeamento das atividades rumo ao fim do projeto. Esse tipo de representação é comum na Teoria de Grafos, sendo que o diagrama PERT/CPM é um grafo direcional.

36


Figura 3.13 – Diagrama de setas PERT/CPM

INÍCIO FIMA

B

C

D

E

F

G

H


Ao analisarmos o exemplo da Figura 3.13, vemos que a atividade A é determinante no início do projeto, e a partir dela há divisão do projeto em três novas atividades, que seguirão caminhos diferentes, as atividades B, C e E. Após a atividade B temos a D, que ao encontrar C determina o início da H. Por outro lado, a atividade E é sequenciada por F e G, que ao encontrar H determina o final do projeto. Esse diagrama até aqui nos é útil para apresentar todas as atividades do projeto e sua sequência, mas não muito mais do que isso.

A informação que está faltando diz respeito ao tempo de cada atividade. Essa informação fundamental pode ser descrita diretamente no diagrama, simplesmente atribuindo o prazo de cada atividade, como na Figura 3.14. Considerando o tempo (dias) definido para cada atividade, podemos perceber três caminhos nesse exemplo:

1. o caminho definido pelas atividades A-B-D-H, que totaliza 25 dias;

2. o caminho definido pelas atividades A-C-H, que totaliza 20 dias;

3. o caminho definido pelas atividades A-E-F-G, que totaliza 13 dias.

Figura 3.14 – Diagrama de setas PERT/CPM e tempo das atividades

INÍCIO FIMA

B

C

D

E

F

G

H

1

2

5

78

10

5

5

Fonte: Adaptação de Faccioni Filho, 2011.

Conforme se percebe no diagrama da Figura 3.14, qualquer atraso no caminho 1 afetará o prazo final do projeto, mas atrasos nos caminhos 2 e 3 não, pois seus prazos totais são inferiores ao do caminho 1, que por isso é considerado o “caminho crítico”.

37


Mas temos que prestar um pouco mais de atenção ao problema, pois no caminho 2, apesar de haver uma folga de 5 dias, essa folga se aplica apenas à atividade C, desde que A e H pertencem também ao caminho 1, que é considerado crítico no projeto. Já no caminho 3 a folga de 12 dias pode ser distribuída estre as atividades E, F e G, conforme decisões da gestão do projeto.

O exemplo é muito simples, mas devemos pensar em projetos mais complicados e com muitas variações de atividades, isso nos dará diagramas bastante extensos e com várias possibilidades de interferência.

O desenho do diagrama pode ser feito com ferramentas de software, algumas delas gratuitas. Porém, o gestor pode desenhar diretamente seu diagrama usando alguns símbolos simples, como os apresentados na Figura 3.15. Além dos símbolos do evento (nó) e da atividade (seta), há na figura alguns outros símbolos importantes para o desenho do diagrama PERT/CPM. O nó com informações tem uma identificação do evento e as datas em que o evento pode ocorrer, ou seja, a “data mais cedo – dc” e a “data mais tarde – dt” de ocorrência do evento. Essas datas podem ser diferentes quando há folga no decorrer das atividades, e com isso o gestor passa a ter uma margem para manobrar o início e fim de uma determinada atividade, sem extrapolar o período de tempo disponível num determinado caminho de execução. Já a seta “fantasma” é uma ligação entre nós mas que não representa uma atividade. A seta é desenhada para perceber a sequência de um determinado caminho.

Figura 3.15 – Símbolos para diagrama de setas PERT/CPM

Nó ou evento - representa o início de uma atividade ou o seu final.

xx

dc dt

Nó com informações - onde são apresentadas informações relativas às datas de início e nome de nó.

dc "data mais cedo" para ocorrer o evento (nó).

dt "data mais tarde" para ocorrer o evento (nó).

xx denominação de nó, geralmente um número.

Seta atividade - seta que define uma atividade; a seta liga dois nós e determina a sequencia do projeto.

Seta fantasma - liga dois nós e determina a sequencia do projeto; não é uma atividade. mas permite visualizar as dependências.

A00

Seta com informações - sobre a seta o nome da atividade (A) e sob a seta a sua duração (00).

FL FL - folga livre que uma atividade te entre dc e dt, ou seja, o tempo de folga para uma atividade começar sem afetar o ptrazo total do projeto.

FT FT - folga total do projeto, considerando as folgas livres das atividades que perfazem o caminho crítico.


38


Se no Gráfico de Gantt é possível ver a escala temporal de maneira muito simples e direta, pela dimensão das barras que representam as atividades, no diagrama PERT/CPM é possível ver com clareza a sequência de atividades com suas precedências, permitindo se notar rapidamente os pontos críticos do projeto. Num projeto de inovação as duas metodologias são úteis, cada uma à sua maneira, e podem certamente fazer parte do ferramental de trabalho do gestor. Elas não substituem nem induzem o modelo de gestão, mas auxiliam aos líderes experientes, como o modelo ágil de gestão de projeto denominado “scrum”, que foi desenvolvido mais recentemente e tem sido aplicado com sucesso em projetos de software.

Modelo Scrum

O modelo Scrum é uma metodologia definida como ágil, muito aplicada para a gestão do desenvolvimento de projetos de software, pois é uma metodologia apropriada para quando há muitas incertezas no planejamento e gestão dos projetos. Essa metodologia é iterativa e incremental, com etapas se sucedendo diariamente, revisões do projeto e planejamento da etapa seguinte.

Essa definição de agilidade e sua aplicação em software tem chamado a atenção das equipes de projeto, que tentam ganhar em desburocratização dos processos de gestão, maior relação entre os membros da equipe, e busca por entregas rápidas e menores no decorrer de todo o projeto. O grande foco do método é o contínuo ciclo de feedback, ou seja, ciclos de curto período em que há a análise e revisão do que foi realizado, com novo planejamento para o ciclo seguinte, visando sempre entregas a cada ciclo.

Scrum é o nome do processo, e não um acrônimo, por isso a grafia em maiúsculas não é correta, apesar de muitas empresas utilizarem assim. O nome é uma analogia ao esforço concentrado e organizado dos jogadores de rugby quando se reúnem junto à bola. Esse processo teve origem em 1986 no artigo de Takeuchi e Nonaka, ao notarem que os projetos teriam um melhor desenvolvimento com pequenas equipes, altamente concentradas e multidisciplinares (TAKEUCHI; NONAKA, 1986). O modelo foi posteriormente desenvolvido e apresentado por Ken Schwaber e Jeff Sutherland em 1995 (SCHWABER; SUTHERLAND, 2013).

Para a gestão de projetos o modelo Scrum tem algumas características que o tornaram bastante utilizado em projetos de inovação, tais como:

• os clientes do projeto tomam parte da equipe de desenvolvimento;

• há entregas a cada fim de ciclo, e nessas entregas o resultado deve corresponder integralmente ao pretendido para o ciclo;

• em cada ciclo há análise de riscos e planejamento para sua mitigação;

• há comunicação constante entre os membros da equipe, com discussões diárias;

• o ciclo é diário, e diariamente a discussão deve responder às perguntas:

· o foi feito ontem para atingir a meta? · o que será feito hoje para atingir a meta do dia? · o que pode impedir o cumprimento dessa meta do dia?

• há transparência total no planejamento e no desenvolvimento;

• nenhum problema é ignorado;

• há aceitação de que o projeto pode mudar, e que o cliente pode alterar os requisitos no decorrer do trabalho, o que é característico dos projetos de inovação.

39


No modelo Scrum há um conjunto de conceitos e definições que acabam por determinar o próprio processo de execução:

• Sprint - os ciclos de desenvolvimento são denominados “sprints”. Cada sprint tem duração limitada, de uma semana a quatro semanas, conforme cada tipo de projeto.

• Sprint planning – é a reunião de planejamento que se dá no início de um sprint. Nessa reunião, o objetivo é detalhado, as atividades são definidas, são feitas as alocações de trabalho e previstas as revisões, e um resultado entregável para cada sprint (meta, incremento) é definido.

• Product backlog – é o conjunto de requisitos definidos pelo “dono do projeto”, ou seja, as funcionalidades desejadas como resultado do projeto.

• Sprint backlog – é o conjunto de requisitos definidos para o período do sprint, ou seja, o “incremento” do projeto a ser entrega na etapa.

• Product owner – é o “dono do projeto”, que pode ser o cliente ou alguém que representa o papel de dono dos requisitos.

• Daily scrum – trata-se de uma reunião diária e de curta duração, em que cada um dos participantes fala dos progressos alcançados e das dificuldades que podem afetar seu trabalho.

• Scrum master – no papel semelhante ao do gestor de projetos, atua como um facilitador é líder para a execução do projeto, já que a equipe é auto-organizada, ou seja, a equipe formula seu próprio gerenciamento durante as constantes reuniões de trabalho.

• Development team – é uma equipe de desenvolvimento, multidisciplinar e auto-organizada, constituída de 5 a 9 membros para o desenvolvimento dos projetos.

• Burndown chart – é um gráfico com eixos X e Y em que são colocadas as atividades com duração máxima de um dia. No eixo X estão os dias que correspondem a um sprint (uma a quatro semanas), e no eixo Y são dispostas as atividades nos dias correspondentes de execução.

Para apoio ao trabalho de gestão no modelo Scrum são utilizadas diversas ferramentas simples, como gráficos, planilhas, anotações, notas, cópias impressas e quadros, sempre visando à agilidade máxima na comunicação e visualização das etapas do projeto.

Para compreender o conceito do Modelo Scrum, podemos analisar os tipos de desenvolvimento convencionais e com sobreposição de etapas. Uma visão desse tema foi apresentado no livro de Faccioni (2011). A Figura 3.16 exemplifica o desenvolvimento sequencial, o sequencial com sobreposição de etapas (quando a etapa seguinte tem início antes do término da etapa anterior) e o de sobreposição total (em que todas as etapas tem algum tipo de sobreposição em relação às outras etapas do projeto).

40


Figura 3.16 – Exemplos de modelos de desenvolvimento sequencial, sequencial com sobreposição de etapas, e com sobreposição total

Idéias, pesquisa

Preparação, Desenvolvimento

Execução, Piloto,

Engenharia Tempo

Tempo

Tempo


No artigo original de Takeuchi e Nonaka (1986) há uma explanação sobre esses três modelos de desenvolvimento, que deram as bases do método Scrum. A Figura 3.17 mostra o projeto desenvolvido de maneira sequencial, aquele que tem sobreposição parcial; e finalmente o de sobreposição total, que é o processo perseguido pelo Modelo Scrum. Na sobreposição, cada etapa interfere nas etapas seguintes, havendo aprendizagem, constante redefinição, melhoria contínua do escopo e mitigação de riscos.

Figura 3.17 – Modelos de desenvolvimento de projetos

A - Sequencial

B - Sobreposição

C - Sobreposição total

1 2 3 4

1 2 3 4

1 2 3 4

Fonte: Adaptação de Takeuchi e Nonaka, 1986.

Por fim, pode-se ilustrar o modelo Scrum num fluxo como o apresentado na Figura 3.18. No início do projeto, o product backlog traz o escopo do projeto, e um sprint será definido pelo planejamento na fase do sprint planning. Esse, por sua vez, cria os documentos do sprint backlog, ou seja, os resultados esperados pelas atividades realizadas naquele sprint específico.

O sprint tem um ciclo total de até quatro semanas (um mês), em que cada dia representa um ciclo de reunião, análise e revisão, programando o dia seguinte, numa sucessão até o final daquele sprint. Como resultado deve-se ter um “entregável”, ou seja, um resultado mensurável que se caracteriza como um “incremento” do projeto total. A partir daí parte-se para um novo sprint até a conclusão final do projeto.

41


Figura 3.18 – Modelo Scrum


Resta-nos então refletir sobre a pergunta: os métodos tradicionais de gestão de projetos valem a pena? São esses métodos úteis para projetos de inovação?

Sem dúvida, há muitas qualidades no Gráfico de Gantt, no modelo PERT/CPM e no Scrum, mas não há necessariamente uma aplicação melhor do que a outra. No mundo inteiro sabe-se que os projetos vêm tendo dificuldades para cumprir prazos, custos e requisitos. Provavelmente, a melhor abordagem de gestão não será utilizar uma determinada ferramenta, ou seguir apenas um modelo. Mas sabemos que, em inovação, o desenvolvimento de projetos precisa ter a capacidade de reavaliações constantes, aprendizagem durante o processo de execução, possibilidade de mudanças de objetivos e tomadas de decisão rápidas. Isso está presente no modelo com sobreposição total, que é atendido pelo Scrum. Assim, uma abordagem com Scrum, valendo-se de ferramentas simples e diretas, como o gráfico de barras e os diagramas de caminho crítico, parece ser algo que vale a pena!

ReferênciasCHRISTENSON, Dale; WALKER, Derek H. T. Understanding the role of “vision” in project success. IEEE Engineering Management Review, v. 32, n. 4, p. 57-73, 2004.

CLELAND, David. The evolution of project management. IEEE Transactions on Engineering Management, v. 51, n. 4, p. 396-397, 2004.

DTI Innovation Report. Competing in the global economy: the innovation challenge. Department of Trade and Industry (DTI), UK. 2013.

DVIR, Dov; SHENHAR, Aaron; ALKAHER, Shlomo. From a single discipline product to a multidisciplinary system: adapting the right style to the right project. IEEE Engineering Management Review, v. 32, n. 1, p. 12-23, 2004.

FACCIONI FILHO, M. Especificação e solução de problemas de engenharia. Florianópolis: CTAI/Senai/SC, 2004. Apostila do Curso de Especialização em Automação e Computação Industrial.

FACCIONI FILHO, M. Gestão de Projetos e de Equipes. Palhoça: Unisul Virtual, 2011.

42


FERNANDES, Jorge Monteiro. Gestão da tecnologia como parte da estratégia competitiva das empresas. Brasília: IPDE, 2003.

IACOVOU, Charalambos; DEXTER, Albert. Turning around runaway information technology projects. IEEE Engineering Management Review, v. 32, n. 4, p. 97-112, 2004.

JXPROJECT. jxProject Company, 2012. Disponível em: <http://www.jxproject.com/index.shtml>. Acesso em: 12 abr. 2016

KESSLER, Eric H.; BIERLY, Paul; GOPALAKRISHNAN, Shanthi. VASA Syndrome: insights from a 17th-Century new-product disaster. IEEE Engineering Management Review, v. 32, n. 1, p. 38-48, 2004.

KLOPPENBORG, Timothy; PETRICK, Joseph. Managing project quality. IEEE Engineering Management Review, v. 32, n. 4, p. 86-790, 2004.

MICROSOFT OFFICE PROJECT. Microsoft Corporation, 2016. Disponível em: <https://products.office.com/pt-br/project>. Acesso em: 12 abr. 2016.

PAAP, Jay; KATZ, Ralph. Anticipating disruptive innovation. IEEE Engineering Management Review, v. 32, n. 2, p. 74-85, 2004.

PAGE-JONES, Meillir. Gerenciamento de projetos: guia prático para restauração da qualidade em projetos e sistemas de processamento de dados. São Paulo: McGraw-Hill, 1990.

PRADO, Darci Santos do. PERT/COM: Série Gerência de Projetos, v. 4. Belo Horizonte: Editora DG, 1998.

PROJECT MANAGEMENT INSTITUTE (PMBOK). Guide to the Project Management Body of Knowledge. 3. ed. 2004.

RAZ, Tzvi; BARNES, Robert; DVIR, Dov. A critical look at Critical Chain Project Management. IEEE Engineering Management Review, v. 32, n. 2, p. 35-44, 2004.

SÁENZ, Tirso W.; CAPOTE, Emilio G. Ciência, inovação e gestão tecnológica. Brasília: IEL/SENAI, 2002.

SCHWABER, Ken; SUTHERLAND, Jeff. The Scrum Guide. Scrum.org. JulyJun., 2013. Disponível em: <http://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf>. Acesso em: 11 abr. 2016.

TAKEUCHI, Hirotaka; NONAKA, Ikujiro. The New Product Development Game. Harvard Business Review, 1986.

http://www.jxproject.com/index.shtml

https://products.office.com/pt-br/project

http://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf

Capítulo 4

O guia PMBOK tem alguma utilidade?

O Project Management Institute - PMI foi criado em 1969 e reúne, atualmente, mais de 650 mil membros interessados em gestão de projetos. É um instituto voltado ao estudo de sistemas e práticas para a gestão de projetos, e certamente é a mais conhecida e respeitada associação que se dedica a esse tema, tendo criado várias publicações e treinamentos, especialmente os que certificam os profissionais de gestão. O PMI lançou, na década de 1990, uma importante publicação tentando reunir o que considera o conhecimento fundamental em gestão de projetos, o guia de melhores práticas conhecido como Guia PMBOK – Project Management Book of Knowledge, sendo a base para as várias certificações de profissionais que o PMI promove ao redor do mundo, sejam elas:

• Certificação PMP – Profissional de Gerenciamento de Projetos (PMP);

• Certificação CAPM – Técnico Certificado em Gerenciamento de Projetos;

• Certificação PfMP - Profissional de Gerenciamento de Portfólio;

• Certificação PMI-PBA - Profissional em Análise de Negócios do PMI;

• Certificação PMI-SP – Profissional em Gerenciamento de Cronograma do PMI;

• Certificação PMI-RMP – Profissional em Gerenciamento de Riscos do PMI;

• Certificação PgMP – Profissional de Gerenciamento de Programas;

• Certificação PMI-ACP – Profissional Certificado em Métodos Ágeis do PMI.

A expectativa do Guia PMBOK é ser a referência básica e final para a área de gestão de projetos. Sendo assim, vamos discutir, na sequência, sua verdadeira utilidade para os projetos de inovação.

O guia PMBOKO Guia PMBOK é totalmente dedicado ao problema da gestão de projetos, e com base nele são feitas as certificações profissionais do PMI. O guia tem tido sucessivas edições, pois como se trata das melhores práticas e várias novas experiências e metodologias são lançadas constantemente, o guia tenta incorporar o que considera as melhores práticas do mercado. Atualmente, na quinta edição, de 2013, o PMBOK tem tido pequenas variações em seu corpo, sendo que as modificações se dão em detalhamentos ou divisões dos capítulos denominados “áreas de conhecimento”.

Para nossa análise de aplicação do PMBOK no mercado e sua importância na gestão de projetos, vamos assumir uma das edições anteriores e analisar suas principais áreas do conhecimento, verificando sua aplicabilidade à gestão de projetos de inovação (PMBOK, 2004). Para isso, vamos nos ater a apenas algumas das unidades internas de cada área do conhecimento.


44


Uma visão geral das áreas de conhecimento em gerenciamento de projetos do PMBOK nos traz nove divisões:

1. Gerenciamento de integração do projeto;

2. Gerenciamento do escopo do projeto;

3. Gerenciamento de tempo do projeto;

4. Gerenciamento de custos do projeto;

5. Gerenciamento da qualidade do projeto;

6. Gerenciamento de recursos humanos do projeto;

7. Gerenciamento das comunicações do projeto;

8. Gerenciamento de riscos do projeto;

9. Gerenciamento de aquisições do projeto.

O gerenciamento de integração do projeto descreve como fazer a integração dos elementos que compõem um projeto, do início ao final, e está dividido internamente em:

• Desenvolvimento do termo de abertura do projeto,

• Desenvolvimento da declaração do escopo preliminar do projeto,

• Desenvolvimento do plano de gerenciamento do projeto,

• Orientação e gerenciamento da execução do projeto,

• Monitoramento e controle do trabalho do projeto,

• Controle integrado de mudanças,

• Encerramento do projeto.

O gerenciamento do escopo do projeto é dedicado a estudar e compreender o problema a ser tratado no projeto, bem como detalhar seus limites. Suas unidades são:

• Planejamento do escopo,

• Definição do escopo,

• Criação da EAP - Estrutura analítica do projeto/Work Breakdown Structure (WBS),

• Verificação do escopo e

• Controle do escopo.

O gerenciamento de tempo do projeto trata dos processos relacionados ao tempo para seu desenvolvimento, prazos, questões relacionadas à organização do cronograma e sobre como tratar os desvios de tempo no projeto. Está dividido em:

• Definição da atividade;

• Sequenciamento de atividades;

• Estimativa de recursos da atividade;

• Estimativa de duração da atividade;

• Desenvolvimento do cronograma,

• Controle do cronograma.

45


O gerenciamento de custos do projeto descreve os processos relacionados a custos, estimativas e orçamentação, assim como controles de gastos. As unidades dessa área são:

• Estimativa de custos;

• Orçamentação;

• Controle de custos.

A área do conhecimento de gerenciamento da qualidade do projeto está relacionada à qualidade do projeto e às garantias para que o projeto satisfaça as condições iniciais colocadas, com as seguintes divisões:

• Planejamento da qualidade;

• Realização da garantia da qualidade;

• Controle da qualidade.

O gerenciamento de recursos humanos do projeto se refere às pessoas que compõem as equipes de projeto, sua contratação e mobilização, como se organizam e como são gerenciadas. As unidades dessa área são:

• Planejamento de recursos humanos;

• Contratação ou mobilização da equipe do projeto;

• Desenvolvimento da equipe do projeto;

• Gerenciamento a equipe do projeto.

O gerenciamento das comunicações do projeto se refere às informações em um projeto, especificamente a geração, coleta, disseminação, o armazenamento e arquivamento, com a seguinte divisão de unidades:

• Planejamento das comunicações,

• Distribuição das informações,

• Relatório de desempenho;

• Gerenciamento das partes interessadas.

O gerenciamento de riscos do projeto está relacionado ao estudo dos riscos, desde a sua identificação, análise, planejamento e controle, com as seguintes unidades:

• Planejamento do gerenciamento de riscos;

• Identificação de riscos;

• Análise qualitativa de riscos;

• Análise quantitativa de riscos;

• Planejamento de respostas a riscos;

• Monitoramento e controle de riscos.

46


O gerenciamento de aquisições do projeto se dedica às compras do projeto, planejamento de compras e contratações, bem como ao relacionamento com fornecedores e encerramento de contratos. Essa área está dividida nas seguintes unidades:

• Planejamento de compras e aquisições;

• Planejamento de contratações;

• Solicitação de respostas de fornecedores;

• Seleção de fornecedores;

• Administração de contrato;

• Encerramento do contrato.

Todas essas áreas de conhecimento em gerenciamento de projetos, resumidas acima, são compostas de unidades nas quais os métodos e ferramentas são desenvolvidos e aplicados. O detalhamento de cada uma nos permitirá compreender seus fundamentos e conceitos, e com isso veremos a aderência do conjunto de conhecimentos aos projetos de inovação.

Gerenciamento de integração do projetoO gerenciamento da integração de projetos está associado a uma visão global do projeto, integrando as diversas partes dele, desde a sua abertura até o encerramento. Essa integração tem o sentido de unificar os diversos processos que percorrem o projeto, cujos passos foram apresentados anteriormente no fluxograma do desenvolvimento do projeto da Figura 3.1 (Capítulo 3). Naquele fluxograma, são ilustradas as etapas do projeto, e há necessidade de que os processos, ferramentas, práticas, documentos e outros itens do projeto sejam compreendidos de maneira integrada. Esse é o objetivo da área de conhecimento do “gerenciamento de integração do projeto” do Guia PMBOK, que está dividido nos tópicos abaixo, sempre com o suporte de ferramentas de gestão e consultoria de especialistas, conforme cada caso:

• formalizar a abertura do projeto, utilizando documentos como o contrato, a declaração inicial e um termo de abertura;

• realizar uma descrição de alto nível com o escopo preliminar do projeto, ou seja, os requisitos principais e os resultados desejados;

• organizar um plano de gerenciamento, que consiste da documentação para definir, preparar, integrar e coordenar o projeto;

• orientar e gerenciar a execução do projeto, com o objetivo de atingir os requisitos do projeto definidos no escopo, incluindo modelos de ações corretivas e preventivas, acompanhamento de entregas parciais do projeto e gestão das informações sobre o seu desempenho;

• monitorar e controlar os processos para iniciar, planejar, executar e encerrar o projeto, atendendo aos objetivos de desempenho pré-definidos, verificando ações corretivas e preventivas implementadas e as mudanças solicitadas no decorrer do projeto;

• gerenciar mudanças, com atualizações de escopo e controle de mudanças do projeto, reparos dos produtos e controle de entregas;

47


• encerrar o projeto, com a finalização de todas as atividades ou de apenas uma de suas fases, concluindo o contrato e também atualizando os ativos organizacionais com o resultado obtido.

A Figura 4.1 ilustra esses tópicos e como se distribuem na área de conhecimento do gerenciamento de integração do projeto.

Figura 4.1 – Visão geral do gerenciamento de integração do projeto

Gerenciamento de Integração do Projeto

Termo de abertura• Contrato• Declaração inicial• Termo de abertura

Ferramentas de gestão Consultoria de especialistas

Escopo preliminar

• Declaração com escopo preliminarFerramentas de gestão Consultoria de especialistas

Orientar e gerenciar a execução

• Modelos de ações corretivas e preventivas

• Entregas parciais do projeto

• Informações sobre o desempenho do projetoFerramentas de gestão

Plano de gerenciamento• Documento com o plano

de gerenciamento do projetoFerramentas de gestão Consultoria de especialistas

Monitorar e controlar• Ações corretivas

e preventivas implementadas

• Mudanças solicitadasFerramentas de gestão Consultoria de especialistas

Gerenciar mudanças

• Atualizações de escopo• Controle de mudanças do

projeto• Reparos


Encerrar o projeto• Produto, serviço ou

resultado final• Encerramento de

contrato• Atualização dos ativos


Fonte: Adaptação do Guia PMBOK, 2004.

Gerenciamento do escopo do projetoO gerenciamento do escopo do projeto se refere à definição de tudo o que deve e não deve estar contido no projeto, bem como seu resultado final. A intenção é garantir um nível de detalhamento elevado, de forma que o projeto chegue ao final com sucesso. A área de conhecimento do gerenciamento do escopo se divide em:

• planejamento do escopo, que documenta como se dará a definição do escopo, sua continuidade e mudanças durante o projeto, e como será a divisão das diversas atividades de execução na estrutura analítica do projeto (EAP), sendo que para isso são usados modelos e normas, bem como a consultoria de especialistas;

48


• definição do escopo, que contém o documento com o escopo detalhado do projeto, no qual todo o trabalho se baseia para sua definição, com as análises e requisitos da partes interessadas (o cliente e outros que possam colaborar nesse detalhamento), e com a consultoria de especialistas;

• criação da EAP, que significa “Estrutura Analítica do Projeto”, e consiste na documentação que divide o projeto em atividades menores, entregas parciais e todas as subdivisões de trabalho, visando a distribuir em pequenos componentes de projeto e facilitar a visão e o gerenciamento das partes. Isso pode ser feito com o suporte de modelos típicos de EAP e outras ferramentas para apoio na decomposição das atividades;

• verificação do escopo, que é o tópico relacionado aos modelos de aceite de entregas parciais, à verificação das atividades e das mudanças solicitadas do projeto, quando necessárias, com o apoio de ferramentas e modelos de inspeção;

• controle do escopo, que contém os procedimentos para controle das alterações de escopo, as ações corretivas e preventivas, as atualizações, as mudanças solicitadas e realizadas, formatadas por meio de ferramentas de gestão e outras técnicas de análise de escopo.

A área de gerenciamento do escopo e suas divisões estão ilustradas no diagrama da Figura 4.2. Um modelo típico (ilustrativo) de estrutura analítica de projetos – EAP – é apresentado na Figura 4.3. Esse modelo divide o projeto de um sistema de automação em seus diversos componentes, visando a distribuir as atividades e pontos a considerar no projeto, desde o seu início até a conclusão. Com isso, a gestão é facilitada e modelos como o de Gantt, o PERT/CPM e o Scrum podem ser aplicados.

Figura 4.2 – Visão geral do gerenciamento do escopo do projeto

Gerenciamento do Escopo do Projeto

Planeiamento do escopo

• Plano de gerenciamento do escopo do projetoModelos e normas Consultoria de especialistas

Definição do escopo• Declaração do escopo do

projeto Análises e requisitos da partes interessadas Consultoria de especialistas

Verificação do escopo

• Modelos de aceite entregas

• Mudanças solicitadas do projeto Ferramentas e modelos de inspeção

Criação da EAP• Documento com Estrutura

Analítica do Projeto - EAPModelos de EAP Ferramentas para apoio na decomposição das atividades

Controle do escopo• Ações corretivas e

preventivas• Atualizações do escopo• Mudanças solicitadas e

realizadasFerramentas de gestão Técnicas de análise


49


Figura 4.3 – Modelo ilustrativo de EAP de projeto de automação

Plataforma de Automoção

Planejamento Desenvolvimento Revisão Implantação Finalização

Contrato

Atividade n

Correções

Comissionamento

Encerramento

Requisitos

Escopo

Equipe

EAP

Software

Hardware

Integração

Atividade 1

Atividade 2

Atividade 3

Atividade 4

Atividade ...

Instalação Termo de Aceite

Manuais


Gerenciamento de tempo do projetoO gerenciamento de tempo do projeto está relacionado a todos os processos que garantam a conclusão do projeto no prazo estipulado. Sabemos que grande parte dos projetos têm seus prazos ultrapassados, o que gera gastos excessivos e contratempos de toda ordem, sendo que alguns projetos podem ser simplesmente cancelados por não terem sido entregues conforme a expectativa de datas.

No gerenciamento de tempo há grande uso de ferramentas de gestão, pois os prazos por atividade são críticos no desenvolvimento dos projetos. Atrasos mínimos em uma atividade podem ter grande impacto no projeto. Basicamente, o prazo determinou, e determina ainda, a criação de metodologias de gestão. Organizar as atividades é mais simples do que realizar o projeto num determinado prazo, prazo esse que pode ser falho por motivos os quais vão de erros em planejamento, problemas com recursos humanos, até a dificuldade e complexidade de realização de atividades, algo comum em projetos de inovação.

De acordo com o diagrama da Figura 4.4, o gerenciamento de tempo está dividido em seis campos:

1. definição da atividade, que identifica e lista todas as atividades específicas do cronograma e seus atributos, e que precisam ser realizadas de acordo com uma lista de “marcos”, ou datas-limite, visando as várias entregas do projeto. Esse conjunto de definições utiliza o conhecimento de especialistas, modelos de decomposição e ferramentas de gestão como suporte de trabalho;

2. sequenciamento de atividades, que considera a interdependência das atividades por meio de análises crítica da sequência, modelos de diagrama de precedência e outras ferramentas, para então documentar todas as dependências entre as atividades do cronograma;

50


3. estimativa de recursos da atividade, que verifica tipo e quantidades de recursos necessários por atividade, as alternativas existentes, análise do tipo “bottom-up”, ou seja, de baixo para cima, com o apoio de ferramentas de gestão e consultoria de especialistas;

4. estimativa de duração da atividade, que a partir de calendário previsto faz a estimativa de períodos de trabalho necessários por atividades individuais, muitas vezes baseadas em analogias com atividades ou experiências semelhantes, bem como em opiniões de especialistas experientes;

5. desenvolvimento do cronograma, que cria o cronograma do projeto com base nos recursos necessários, restrições, durações e sequências, mantendo calendário atualizado em suas ferramentas de gestão, diagramas de barras e visualização do caminho crítico;

6. controle do cronograma, que faz as medições de desempenho, análises de variação, gráficos comparativos entre o que foi planejado e realizado, visando ao controle das mudanças no cronograma do projeto e mantendo as atualizações em ferramentas de gestão.

Figura 4.4 – Visão geral do gerenciamento de tempo do projeto

Gerenciamento de Tempo do Projeto

Definição Atividade

• Lista de atividades• Atributos das atividades• Lista de marcos/entregas

Ferramentas de gestão Consultoria de especialistas Modelos de decomposição

Sequenciamento• Modelo de diagrama de

precedência• Análise crítica da sequência

Ferramentas de gestão Gantt PERT/CPM Scrum

Estimativa de duração

• Calendário• Estimativa por atividade• Opiniões de especialistas

experientesFerramentas de gestão Analogias

Estimativa de Recursos

• Recursos necessários por atividade

• Alternativas existentesFerramentas de gestão Consultoria de especialistas "Estimativa "bottom-up

Cronograma

• Cronograma do projeto• Calendário atualizado de

atividades e de recursosFerramentas de gestão Diagrama de barras Caminho crítico

Controle cronograma

• Atualizações de cronograma• Medições de desempenho• Análise de variação

Ferramentas de gestão Gráficos comparativos planejado/realizado


51


Gerenciamento de custos do projetoO gerenciamento de custos do projeto se constitui dos processos necessários para planejar, estimar, orçar e controlar os custos do projeto, de tal forma que possa ser concluído dentro do orçamento aprovado inicialmente.

Desde os primórdios das teorias de gestão de projetos fala-se dos problemas relacionados a custos, e os métodos desenvolvidos têm como meta manter esses custos e os prazos dentro dos limites previstos. Como já vimos, isso muitas vezes não tem sido alcançado, por fatores os mais diversos. Projetos constantemente ultrapassam os valores previstos, e algumas vezes de forma drástica, pelo dobro ou triplo. É difícil aceitar esses erros e a procura pelo que determinou tal problema é uma constante. Processos de controle cada vez mais rígidos, a melhoria nas estimativas iniciais, o aperfeiçoamento de modos de gestão, entre vários outros mecanismos, está em constante evolução.

A área de gerenciamento de custos, conforme a Figura 4.5, está dividida em três tópicos:

1. estimativa de custos por atividade, que determina os valores dos recursos existentes, compreende os custos de qualidade e incorpora propostas de fornecedores e estimativas análogas, consolidando-as em cronogramas físico-financeiros (ver exemplo na Figura 4.6) e em ferramentas de gestão;

2. orçamentação do projeto, que compreende a consolidação dos custos estimados das diversas atividades, estabelecendo uma tabela básica dos custos em planilhas e ferramentas de gestão, para então fazer a reconciliação com os limites de orçamento do projeto;

3. controle de custos, com atualizações constantes e medições de desempenho por meio de indicadores de gastos, fazendo, então, as previsões de término por atividade, etapa e projeto global, por meio do auxílio de planilha comparativa entre o previsto/realizado, acompanhamento do cronograma físico-financeiro e ferramentas de gestão.

Figura 4.5 – Visão geral do gerenciamento de custos do projeto

Gerenciamento de Custos do Projeto

Estimativa de custos

• Estimativa de custos por atividade

• Determinação de valores dos recursos existentes

• Custos de qualidadeFerramentas de gestão Propostas de fornecedores Estimativas análogas Cronograma físico-financeiro

Orçamentação

• Agregação dos custos• Reconciliação com limites de

orçamentoFerramentas de gestão Planilhas

Controle de custos

• Atualizações de custos• Previsões de término• Medições de desempenho• Indicadores de gastos

Ferramentas de gestão Planilhas comparativas planejado/realizado


52


Figura 4.6 – Exemplo de cronograma físico-financeiro, que associa os custos ao calendário de atividades


Gerenciamento da qualidade do projetoO gerenciamento da qualidade do projeto envolve as atividades relacionadas às políticas de qualidade, visando ao atendimento máximo do escopo e à motivação original do projeto.

Problemas na qualidade afetam custos, além do desgaste na imagem do produto final e da equipe de trabalho. Por isso, uma série de ações deve ser tomada no sentido de garantir a qualidade no processo completo do projeto, conforme ilustrado na Figura 4.7:

• realizar um planejamento da qualidade, que identifica padrões de qualidade relevantes, gerando um plano de gerenciamento com a definição de indicadores e métricas, ações de melhoria, realização de benchmarking, análise de custo-benefício, e assim satisfazer os requisitos e escopo do projeto;

• realizar a garantia da qualidade, que trata de aplicar o planejamento de qualidade de forma sistemática, empregando os processos necessários para atender aos requisitos originais por meio de ações corretivas, mudanças, atualizações do plano de gerenciamento da qualidade, com o auxílio de auditorias, planilhas de controle e ferramentas de gestão;

• controlar a qualidade, monitorando os resultados específicos e realizando a validação de entregas, as medições de controle, as ações corretivas e preventivas, as amostragens e inspeções contínuas, com o apoio de ferramentas de gestão, planilhas e gráficos comparativos.

53


Figura 4.7 – Visão geral do gerenciamento da qualidade do projeto

Planejamento

• Plano de gerenciamento da qualidade

• Definição de indicadores e métricas da qualidade

• Planos de melhoriaBenchmarking Análise de custo-benefício Ferramentas de gestão

Garantir qualidade

• Ações corretivas• Mudanças solicitadas• Atualizações do plano de

gerenciamenrto da qualidadeFerramentas de gestão Planilhas de controle Auditorias

Gerenciamento da Qualidade do Projeto

Controle de qualidade

• Validação de entregas• Medições de controle• Ações corretivas e preventivas• Acompanhamento de

indicadoresFerramentas de gestão Planilhas e gráficos comparativosAmostragem Inspeção contínuaTécnicas de qualidade


Gerenciamento de recursos humanos do projetoO gerenciamento de recursos humanos do projeto é definido como o que contém os processos de organização e gerenciamento da equipe do projeto. A equipe é composta por todas as pessoas que têm funções e responsabilidades relacionadas ao projeto, seja na execução, na gestão ou no controle, de acordo com as estruturas de equipe de projeto vistas anteriormente. Sabe-se que o envolvimento dos membros da equipe em todas as etapas, inclusive nas decisões, fortalece a estrutura geral do projeto, mas isso depende fortemente da estrutura adotada e do tipo de gestão e liderança. Não é por se adotar um tipo de estrutura e um controle rígido das etapas, como por exemplo no modelo Scrum, que se poderá garantir o sucesso de um projeto. A dependência de um líder, em especial nos projetos de inovação, parece ser um diferencial decisivo.

A área de conhecimento, no PMBOK, do gerenciamento dos recursos humanos, está dividida em quatro tópicos, conforme ilustrado na Figura 4.8 e no seguinte descritivo:

• planejamento de recursos humanos, que identifica e documenta todas as funções de pessoal no projeto, bem como as relações hierárquicas e atribuições, na forma de um plano de gerenciamento de pessoal e organograma com a estrutura da equipe;

• mobilização da equipe do projeto, que busca obter os recursos humanos necessários ao projeto de acordo com a disponibilidade desses recursos, sendo que alguns já podem estar presentes na organização e serão designados para o projeto, enquanto outros deverão ser negociados e contratados;

• desenvolvimento da equipe, com a melhoria de competências, treinamentos, atividades de formação, premiações (quando pertinente) e constante avaliação de desempenho da equipe;

54


• gerenciamento da equipe do projeto, com o acompanhamento e avaliação do desempenho, fornecimento de feedback, ações corretivas e preventivas, gerenciamento de conflitos, registros de ações e problemas, com o apoio de ferramentas de gestão de recursos humanos.

Figura 4.8 – Visão geral do gerenciamento dos recursos humanos do projeto

Planejamento da equipe

• Plano de gerenciamento de pessoal

• Organograma do projeto e estrutura da equipeFerramentas de gestão Networking

Mobilização da equipe

• Disponibilidade de recursos humanosNegociação Contratos de pessoal Designação

Desenvolver a equipe

• Avaliação de desempenho da equipeTreinamento Atividades de formação Premiações

Gerenciar a equipe

• Ações corretivas e preventivas• Mudanças solicitadas• Gerenciamento de conflitos

Avaliação de desempenho Registro de ações e problemas Ferramentas de gestão

Gerenciamento de Recursos Humanos do Projeto


Gerenciamento das comunicações do projetoO gerenciamento de comunicações do projeto é a área de conhecimento que contém os processos de geração, coleta, distribuição, armazenamento, recuperação e envio das informações do projeto para os membros e partes interessadas. É responsável por estabelecer as relações entre as pessoas e as informações pertinentes, visando com que a comunicação no interior do projeto seja bem-sucedida.

Muitos projetos fracassam porque as comunicações são inapropriadas, truncadas ou falhas, o que pode gerar falhas de execução e conflitos internos. Por esse motivo, o gestor do projeto, seja convencional ou de inovação, deve dispender tempo e esforço nesse tópico, o que pode ser fator crítico para o sucesso.

O gerenciamento das comunicações, como ilustrado na Figura 4.9, está subdivido nos seguintes quatro itens:

1. planejamento das comunicações, que determina as necessidades de informações e comunicações no projeto por meio de um plano de gerenciamento das comunicações, com seus requisitos gerais e com o uso de ferramentas de Tecnologia da Informação – TI;

55


2. distribuição das informações, ou seja, disponibilização das informações necessárias à equipe e às partes interessadas, no momento adequado, bem como a definição de mudanças no plano, com o uso de métodos e ferramentas de distribuição das informações;

3. relatórios de desempenho, incluindo as ações corretivas tomadas, as previsões, os relatórios de prazos e de custos, com o auxílio de ferramentas de TI e outros instrumentos de comunicação;

4. gerenciamento das partes interessadas, registrando, relatando e coordenando a resolução de problemas, mudanças, ações corretivas e preventivas.

Figura 4.9 – Visão geral do gerenciamento das comunicações do projeto

Planejamento das comunicações

• Plano de gerenciamento das comunicações Requisitos gerais de comunicações Ferramentas de Tecnologia da Informação - TI

Distribuição das informações

• Mudanças no Plano conforme solicitações Métodos de distribuição das informaçõesFerramentas de TI

Relatório de desempenho

• Relatórios de desempenho• Ações corretivas • Previsões

Relatórios de prazos Relatórios de custos Ferramentas de TI

Gerenciar as partes interessadas

• Ações corretivas e preventivas• Mudanças

Registro de ações e problemas Ferramentas de TI

Gerenciamento das Comunicações do Projeto


Gerenciamento de riscos do projetoO gerenciamento de riscos do projeto está relacionado aos processos de identificação, análise, reação e respostas, monitoramento e controle dos riscos do projeto, e para isso realiza um planejamento prévio e de acompanhamento contínuo durante a sua realização. Seus objetivos são diminuir as probabilidades e os impactos dos eventos adversos ao projeto, além de aumentar a probabilidade e o impacto dos eventos positivos.

O gerenciamento de riscos do projeto está dividido conforme ilustrado na Figura 4.10, e são seis as suas subdivisões:

1. planejamento do gerenciamento de riscos, que contém um plano sobre como abordar, planejar e executar as atividades de gerenciamento de riscos, que se dá por meio de análises, reuniões de planejamento e no uso de ferramentas de avaliação;

56


2. identificação de riscos, em que se determinam os riscos que podem afetar o projeto, com sua respectiva documentação, registro, relatórios de estudos de riscos, com o auxílio de ferramentas de gestão e coletas diversas de informações (a Figura 4.11 apresenta um típico relatório de estudo de riscos);

3. análise qualitativa de riscos, que define uma priorização dos riscos para análise ou para ação, por meio de avaliações e combinação de probabilidade de ocorrência e impacto. Para isso, são realizadas categorizações, registros, avaliação de impacto e construídas matrizes de probabilidades, com o auxílio de ferramentas de gestão, quando disponíveis;

4. análise quantitativa de riscos, que é a análise numérica dos efeitos dos riscos no projeto, e se dá por coleta de dados, técnicas de modelagem e apoio de ferramentas de gestão;

5. planejamento de respostas a riscos, que necessita da atualização constante de registros e depende, também, de acordos contratuais relacionados a riscos, acordos esses que definem estratégias de resposta a riscos positivos e negativos;

6. monitoramento e controle de riscos, que se dá pelas atualizações de registros de riscos e pelo acompanhamento, monitoramento, identificação de novos riscos, execução de planos de respostas, reavaliações de riscos, auditorias e análises de tendências.

Figura 4.10 – Visão geral do gerenciamento de riscos do projeto

Gerenciamento de Riscos do Projeto

Planejamento

• Plano de gerenciamento de riscos Análise e reuniões de planejamentoFerramentas de avaliação

Identificação

• Registro de riscos• Relatórios de estudos de

riscosFerramentas de gestão Técnicas com diagramas Coleta de informações

Registro a riscos

• Atualização de registros• Acordos contratuais

relacionados a riscosFerramentas de gestão Estratégias de resposta a riscos positivos e negativos

Análise qualitativa

• Atualização de registros• Avaliação de impacto• Categorização dos riscos

Matriz de probabilidades Ferramentas de gestão

Análise quantitativa

• Atualização de registros• Coleta de dados

Ferramentas de gestão Técnicas de modelagem

Monitoramento e controle

• Atualizações de registros de riscos

• Reavaliações de riscos• Auditorias• Análises de tendências

Ferramentas de gestão Relatórios de acompanhamento


57


Figura 4.11 – Relatório ilustrativo de estudo de riscos

Estudo de riscos<nome do projeto>

Equipe de estudo:Local e data:

Resumo do projeto (escopo, objetivos, estratégias)

Riscos quanto aos benefícios: - o cliente tem uma ideia exata do resultado a ser obtido? - ou se tem uma ideia aproximada? - é possível medir os benefícios?

Descrição:

Riscos quanto aos benefícios: - qual a probabilidade desse tipo de riscos? - qual o seu impacto?

Descrição:

Riscos quanto aos recursos: - há equipamentos de reserva? - há pessoal de reserva - a tecnologia empregada é inteiramente dominada?

Descrição:

Riscos quanto aos recursos: - qual a probabilidade desse tipo de riscos? - qual o seu impacto?

Descrição:

Riscos quanto aos custos: - o financiamento de todo o projeto está garantido? - há um montante de reserva?

Descrição:

Riscos quanto aos custos: - qual a probabilidade desse tipo de riscos? - qual o seu impacto?

Descrição:

Riscos quanto ao prazo: - há fatores internos ou externos, não considerados, que podem afetar o prazo do projeto?

Descrição:

Riscos quanto ao prazo: - a equipe de projeto é experiente?

Descrição:

Riscos quanto ao prazo: - qual a probabilidade desse tipo de riscos? - qual o seu impacto?

Descrição:

Lista dos 10 riscos mais importantes:

Podemos conviver com eles?

É possível atenuá-los?

É possível evitá-los?

Conclusões quanto aos riscos do projeto:

Anexos (tabelas, demonstrativos, estatísticas, reportagens, tendências tecnológicas e comercias etc)


58


Gerenciamento de aquisições do projetoO gerenciamento de aquisições do projeto compreende os processos de aquisição de produtos, serviços ou soluções externas ao projeto, visando à realização do trabalho. Inclui o gerenciamento e a administração dos contratos, inclusive a dos membros externos à equipe e incluídos para a realização do projeto.

Esse gerenciamento está dividido em seis subdivisões, de acordo com a visão geral apresentada na Figura 4.12. Essas subdivisões são assim descritas:

• planejamento de compras e aquisições, que envolve o plano de compras, determinando o que comprar, quando e como fazer isso, a partir de modelos de contratos e do apoio de consultoria especializada, quando necessário;

• planejamento de contratações que contém os critérios de avaliação, requisitos e especificações de produtos e serviços a adquirir, identificação de possíveis fornecedores, modelos de documentos de aquisição e outros formulários; o que pode também ter o apoio de consultoria especializada;

• solicitação de respostas de fornecedores a partir de uma lista de fornecedores qualificados, com o objetivo de obter informações, cotações, preços, ofertas ou propostas; o que se dará após anúncios e chamadas de proposta e possíveis reuniões com proponentes;

• seleção de fornecedores, por meio de técnicas de análise, ponderação, avaliação, e posterior negociação de um contrato por escrito com cada fornecedor selecionado;

• administração de contratos a partir de um plano de gerenciamento de contratos que estabelece o modelo de relação entre o comprador e o fornecedor, as análises de desempenho, as auditorias e o sistema de pagamentos, com o auxílio de ferramentas de gestão e acompanhamento de contratos;

• encerramento do contrato para concluí-lo, incluindo a resolução de itens em aberto, com a atualização dos ativos organizacionais e a auditoria de aquisições, processos no quais as ferramentas de gestão podem, também, desempenhar papel.

59


Figura 4.12 – Visão geral do gerenciamento de aquisições do projeto

Gerenciamento de Aquisições do Projeto

Planejamento de compras e aquisições

• Plano de compras• Contratos de compra

Modelos de contratos Consultoria especializada

Planejar contratações

• Contratos de trabalho• Critérios de avaliação• Documentos de aquisição

Formulários padrão Consultoria especializada

Administração de contratos

• Documentos contratuais• Plano de gerenciamento de

contratos Análise de desempenho de fornecedorAuditorias Sistema de pagamentos Ferramentas de gestão

Solicitação de resposta de fornecedores

• Lista de fornecedores qualificados

• Documentos de aquisição• Propostas

Anúncios e chamadas de propostaReuniões com proponentes

Seleção de fornecedores

• Fornecedores selecionados• Contratos• Alocação de recursos

Ferramentas de gestão ,Técnicas de análise ponderação e avaliaçãoNegociação

Encerramento de contratos

• Contratos encerrados• Atualização dos ativos

organizacionais• Auditoria de aquisições

Ferramentas de gestão


O Guia PMBOK é bastante extenso e vem sofrendo contínuas revisões e ampliações no decorrer do tempo. Isso o tem destacado no mercado mundial de gestão de projetos, sendo que milhares de pessoas já buscaram e conquistaram certificados profissionais desse instituto, o que nos levou a abrir a questão: o guia PMBOK tem alguma utilidade?

Sem dúvida, o guia se comporta como um “guia”, no sentido de que não dá respostas aos gestores de projetos, apenas são indicados caminhos para que sigam o que considerarem relevante em seus trabalhos. Nesse sentido, certamente o PMBOK tem grande utilidade. No entanto, ao contrário do que muitos gestores acreditam e defendem, ele não traz uma receita infalível e definitiva para a gestão de projetos, especialmente quando tratamos de assuntos de alta inovação. Para isso, muitas das técnicas expostas no guia não são adequadas, e podem inclusive ser problemáticas, tal o nível de burocratização exigido nos processos de gestão.

Assim, a resposta à pergunta inicial é “sim”, quando tratamos da utilidade geral do guia para projetos convencionais. E “depende”, quando tratamos de criações inovadoras.

ReferênciasFACCIONI FILHO, M. Gestão de Projetos e de Equipes. Palhoça: Unisul Virtual, 2011.

PROJECT MANAGEMENT INSTITUTE (PMBOK). Guide to the Project Management Body of Knowledge. 3. ed. 2004.

Capítulo 5

Há métodos especiais para a gestão de projetos de inovação?

Projetos de inovação geralmente são definidos de forma muito abrangente, não muito precisa. Nesses projetos, objetivos ambíguos são comuns e vão se solidificando e refinando no decorrer do próprio projeto. Equipes de projetos de inovação são multidisciplinares e com grande interdependência de confiança entre pares.

Em projetos de inovação, as falhas e insucessos são aceitos, pois servem para aprendizagem e ajudam a ir adiante, em busca de desafios, às vezes, ainda maiores. Por isso, os processos rígidos e formais são rejeitados, e as equipes “fogem” deles.

Por esses motivos, projetos de inovação exigem novos métodos de gestão?

Os projetos de inovação exigem novos modelos comportamentais de gestão, não necessariamente novos métodos ou técnicas. Na prática, os métodos estão todos aí; o que é necessário é uma nova abordagem para essas técnicas, extraindo de várias delas o que se aplica à gestão da inovação.

A Figura 5.1 apresenta um resultado muito interessante da relação entre inovação e o papel da gestão de projetos (VARMA, 2012). O gráfico apresenta, no eixo vertical, o índice de inovação de países, e no eixo horizontal, o número de gestores de projetos certificados, por milhão de habitantes, desses mesmos países. Os certificados referem-se às diversas certificações obtidas de cursos e treinamentos, como os do PMI, por exemplo.

O gráfico relaciona países europeus, além dos Estados Unidos, Canadá, Japão e Austrália. Observando os países com maior índice de inovação, percebe-se uma razoável variação no número de certificados para dois países com o mesmo índice, tais como Japão e Alemanha, de um lado; Estados Unidos e Dinamarca do outro. No caso dos primeiros temos um número de certificações próximo a 300 por milhão, e no caso da Dinamarca temos mais de ~800 por milhão. Distância mais destacada ainda se dá entre França e Bélgica (~100 por milhão) e Canadá (800 por milhão). Isso pode querer dizer que o número de certificações não comprova maior ou menor inovação.

Mas outra análise merece destaque, que é a dos países com baixa inovação. Todos estão concentrados num grupo de baixo número de certificações. Não sabemos se o número de certificações maior leva a mais inovação, mas certamente um baixo número de certificações representa baixa inovação. Não temos dados do Brasil para comparar.


61


Figura 5.1 – Índice de inovação versus certificações de gestão de projeto

Fonte: Varma, 2012.

O gráfico também evidencia que os países com maior índice de inovação são justamente os que ocupam posição destacada em índices de crescimento, IDH e outros índices de qualidade de vida e no aspecto econômico. Isso não parece ser uma coincidência.

Outras evidências do gráfico se referem às culturas desses países, pois os do norte europeu ocupam a parte superior do gráfico. Também não parece ser uma coincidência, pois a literatura e notícias de imprensa sempre nos mostram o ambiente meritocrático que reina nesses ambientes, diferente do ambiente processual e hierárquico de vários dos demais.

A Figura 5.2 apresenta o volume de investimento das empresas em P&D – Pesquisa & Desenvolvimento, frente ao PIB de seus países. Os Estados Unidos, mesmo com seu imenso Produto Interno Bruto, mantêm a liderança em gastos totais, sendo que tais gastos são feitos pelas empresas, e não pelo governo.

62


Figura 5.2 – Investimentos empresariais em pesquisa e desenvolvimento, em percentagem do PIB

1992 1997 1998 1999 2000 2001 2002

Finland* 1.21 1.79 1.94 2.20 2.41 2.42

Germany 1.66 1.54 1.57 1.70 1.75 1.76 1.75

France* 1.49 1.39 1.35 1.38 1.37 1.37

UK 1.39 1.16 1.17 1.23 1.19 1.23 1.24

EU average 1.18 1.13 1.14 1.19 1.22 1.24

USA 1.90 1.91 1.94 1.98 2.04 2.10 2.06

Fonte: DTI Innovation Report, 2013.

A meritocracia convive com o líder muito melhor do que com o gerente. E a frase “só os fortes sobrevivem” é aliada da meritocracia, para o bem ou para o mal. Com certeza, para o bem, quando falamos em inovação e criação.

Modelos novos de gestão de projetos estão sendo propostos todos os dias, em todos os congressos de gestão e nas mais diversas empresas. Outra vez cabe a pergunta: eles são úteis? Sim, desde que a cultura da inovação esteja estabelecida e aceita. Sem isso, serão processos e mais processos tentando “alinhar” as atividades em projetos que terão resultados “convencionais”.

ReferênciasVARMA, Tathagat. Project Management Vs. Innovation: Friends or Foes?! 2012. Disponível em: <http://pt.slideshare.net/Managewell/project-management-vs-innovation-friends-or-foes?from_action=save>. Acesso em: 18 abr. 2016.

DTI Innovation Report. Competing in the global economy: the innovation challenge. Department of Trade and Industry (DTI), UK. 2013.

http://pt.slideshare.net/Managewell/project-management-vs-innovation-friends-or-foes?from_action=save

http://pt.slideshare.net/Managewell/project-management-vs-innovation-friends-or-foes?from_action=save

63


Considerações finais

Mais dúvidas do que certezas parece ter sido o tom deste livro.

Inicialmente, procuramos estabelecer o que seria um projeto de inovação, passando pelos conceitos comuns da literatura especializada, tentando compreender o nascimento e o ciclo de um projeto convencional e o que diferencia uma inovação incremental de uma inovação disruptiva ou radical. O mundo da tecnologia e a internet trouxeram também o novo jargão, “killer application”, para dificultar ainda mais os conceitos nesse mercado sempre em mutação.

Se o mercado da inovação é ágil, a problemática, então, é a questão da gestão dos projetos de inovação. Temos as características dos gestores com perfil de gerente, ou “chefe”, e dos líderes. E todos eles precisam se ajustar e conduzir as diversas estruturas possíveis de equipe, desde as mais convencionais até as totalmente horizontais. Para isso, vários métodos de apoio à gestão são empregados, como os gráficos de Gantt, o modelo PERT/CPM, e o mais recente modelo Scrum, que praticamente se apropriou dos projetos de software.

Nesse cenário, surgiram vários organismos, associações e institutos voltados ao estudo da gestão de projetos, sendo o de maior destaque o PMI – Project Management Institute, que criou o guia PMBOK, discutido no capítulo 4. O guia PMBOK comporta-se justamente como guia, e não uma técnica capaz de, por si só, conduzir projetos com sucesso.

Sendo a questão da gestão de projetos um caso polêmico (ao tentar descobrir qual o melhor método), mais ainda será se nos perguntarmos se há métodos especiais para a gestão de projetos de inovação.

Há?

64


Sobre o conteudista

Mauro Faccioni Filho

Graduado em Engenharia Elétrica pela Universidade Federal de Santa Catarina - UFSC (1985), mestrado (1997) e doutorado em Engenharia Elétrica (UFSC 2001). Pós-Doutorado no tema “Social Network Analysis” pela University of London, Queen Mary College (2006). Diretor e sociofundador das empresas Fazion Sistemas Ltda. (plataformas e aplicativos para celulares) e Creare Fazion Ltda. (soluções de infraestrutura e automação para Data Centers).

É coordenador e professor de curso superior e de pós-graduação da UNISUL - Universidade do Sul de Santa Catarina, na modalidade da educação a distância. É certificado ATD pelo Uptime Institute (USA), e membro do comitê CE-03:046.05, Norma 14565:2013 da ABNT. Recebeu, em 2012, pelo desenvolvimento da plataforma de software DataFaz DCIM, o prêmio “Ideia para o Futuro & Conceitos de Design”, do DatacenterDynamics Awards.

Na Universidade Federal de Santa Catarina, UFSC, foi colaborador em pesquisas de eletromagnetismo e modelagem numérica no Laboratório Maglab (2001 a 2003). Foi Diretor do Centro de Tecnologia em Automação e Informática, CTAI/SENAI (2002 a 2004). Durante a pesquisa do projeto de mestrado realizou estágio na University of Nottingham, Inglaterra (1999).

Em literatura publicou livros de poesia (Olhos cegos, Editora Letras Contemporâneas, 2004; Duplo dublê, Editora Letras Contemporâneas, 2002; Helenos, Editora Letras Contemporâneas, 1998), e foi co-editor da Revista Babel, Poesia e Crítica (2000-2002).

Documents

Gestão de projetos de inovação - oitonovetres.com.br€¦ · A chegada da era da computação também trouxe a sua contribuição, com o lançamento de inúmeras ferramentas para