Este artigo tem como objetivo demonstrar a importância do comprometimento dos stakeholders para o sucesso dos projetos e ampliar a visão quanto ao gerenciamento dos mesmos e sua relação com os stakeholders, apresentando dois casos em uma mesma empresa, com o mesmo sponsor e o mesmo gerente de projetos. Um dos projetos obteve sucesso, o outro caminhou para o fracasso. Serão apresentadas informações que levarão a compreender que as causas do sucesso e fracasso dos projetos estão diretamente relacionadas com o comprometimento dos stakeholders.
Palavras Chaves: Stakeholders; Comprometimento; Gestão;
Abstract
The main objective of these article is demonstrate the importance of the stakeholders commitment in the project success and expand the vision on the management them, presenting two cases in the same company with the same sponsor and project manager. One of the projects succeeded, the other failed. Information will be presented about the cases in other to understand the causes of success and failure that are directly related to the commitment of the stakeholders.
Keywords: Stakeholders; Commitment; Management;
Num ambiente de projetos, muitas são as variáveis que um gerente de projetos precisa, estando sempre atento para poder obter sucesso. Muitas destas são identificadas de imediato como entraves para alcançar o sucesso do projeto e corre-se o risco de ficar focado apenas nelas. Por outro lado, existem outras variáveis que passam despercebidas ou quase, e é nelas que é preciso estar atento, pois podem ser o elo mais fraco da corrente.
Este trabalho tem como objetivo demonstrar, através de dois casos, a importância do comprometimento dos stakeholders nos projetos como fator determinante para o sucesso, o qual é por muitas vezes deixado de lado em detrimento da especificação de escopo, tempo, custo e qualidade do projeto.
Este trabalho foi orientado baseado na seguinte pergunta: “Por que alguns projetos atingem o sucesso e outros fracassam?”. Para que se respondesse a interrogação, foi considerado oportuno adotar como estratégia de pesquisa o estudo de caso qualitativo, o qual é indicado em investigações que buscam responder a este tipo de questão (Yin, 1994).
A análise dos dados foi iniciada enquanto se fazia a coleta dos mesmos, conforme indicado por Merriam (1998), através de anotações em um diário de campo das observações e reflexões sobre o que estava se passando. A categorização dos dados foi efetuada, com base na Grounded Theory de Glaser & Straus (1967), que ressalta duas estratégias mais importantes, a primeira estratégia é o método constante de comparação, em que o pesquisador simultaneamente codifica e analisa os dados coletados para criar conceitos; através de constantes comparações de incidentes específicos nos dados, o pesquisador refina estes conceitos, identifica as propriedades, explora a relação entre os dados e as integra em uma teoria coerente.
A segunda estratégia é o método da amostragem teórica, em que o pesquisador seleciona novos casos de estudo de acordo com o potencial dos mesmos em ajudar a expandir ou refinar os conceitos e teorias já criados previamente.
A Grounded Theory permite captar a essência do fenômeno, dando sentido aos dados coletados através do “agrupamento de conceitos que parecem pertencer ao mesmo fenômeno” Strauss e Corbin (1990, p. 65). Isso exige a comparação constante dos dados, um movimento de “ir e vir entre pedaços concretos de dados e conceitos abstratos, entre o raciocínio indutivo e dedutivo, entre a descrição e a interpretação” Merriam (1998, p. 178).
Tratar de gerenciamento de projetos envolve portfólio, programas, projetos, sponsor, stakeholders, gerente de projeto e outros temas de igual relevância. Este tópico do trabalho procura apresentar os temas citados pertinentes ao objeto em estudo que servem como base teórica encontrada na literatura científica para melhor entendimento e discussão do problema apresentado. Depois, na conclusão do trabalho, as referências serão usadas para fundamentar os argumentos apresentados para atingir o sucesso em projetos, programas e portfólios.
Para o PMBOK(2008) Um portfólio é:
Um conjunto de projetos ou programas e outros trabalhos agrupados para facilitar o gerenciamento eficaz desse trabalho a fim de atender aos objetivos de negócios estratégicos. Os projetos ou programas no portfólio podem não ser necessariamente interdependentes ou diretamente relacionados. É possível atribuir recursos financeiros e suporte com base em categorias de risco/premiação, linhas de negócios específicas ou tipos de projetos genéricos, como infra-estrutura e melhoria dos processos internos.
Dye e Pennypacker (2000) consideram o portfólio como um “conjunto de investimentos. Uma coleção de projetos que, na soma, constitui a estratégia de investimentos da organização.”
Já a Gestão de Portfólio de projetos é definida por Cooper et al. (1997) como um processo de decisão dinâmico, onde a lista de projetos ativos é constantemente atualizada e revisada. Nesse processo, novos projetos são avaliados, selecionados e priorizados; projetos existentes podem ser acelerados, finalizados ou ter sua prioridade diminuída, sendo que os recursos são destinados, em sua maioria, para os projetos ativos.
Segundo o PMBOK(2008) a gestão de portfólio:
é maximizar o valor do portfólio através do exame cuidadoso dos projetos e programas candidatos para inclusão no portfólio e da exclusão oportuna de projetos que não atendam aos objetivos estratégicos do portfólio. Outras metas são equilibrar o portfólio entre investimentos incrementais e radicais e para o uso eficiente dos recursos.
Dye e Pennypacker (2000) consideram como gestão de portfólio, “a arte e a ciência de aplicar conhecimento, competências, ferramentas e técnicas a uma coleção de projetos com o objetivo de atingir ou superar as expectativas da estratégia de investimentos de uma organização.”
Normalmente, cabe aos diretores e equipes de gerenciamento da diretoria assumir a responsabilidade de gerenciar os portfólios de uma organização, por se tratar da estratégia da empresa PMBOK(2008).
Quanto a programa, o PMBOK(2008) define como “um grupo de projetos relacionados gerenciados de modo coordenado para a obtenção de benefícios e controle que não estariam disponíveis se eles fossem gerenciados individualmente”.
Thiry (2000) segue na mesma linha, definindo-o como “uma coleção de ações de mudança (projetos e atividades operacionais) agrupada propositalmente para realizar benefícios táticos ou estratégicos para a organização.” Dobson (1999) por sua vez, se refere a programas como conjunto de projetos interdependentes, que caracteriza um programa, de “portfólio”, e trata desse portfólio como se fosse um grande projeto, na tentativa de simplificar a estratégia de seu gerenciamento. Uma definição um pouco conturbada em relação a programas e portfólios.
A norma ISO 10006 (1997), define projeto como sendo “um processo único, consistindo de um grupo de atividades coordenadas e controladas com datas para início e término, empreendido para o alcance de um objetivo conforme requisitos específicos, incluindo limitações de tempo, custo e recursos”. Tuman (1983) diz que:
Um projeto é uma organização de pessoas dedicadas visando atingir um propósito e objetivo específico. Projetos geralmente envolvem gastos, ações únicas ou empreendimentos de altos riscos no qual tem que ser completado numa certa data por um montante de dinheiro, dentro de alguma expectativa de desempenho. No mínimo todos projetos necessitam de terem seus objetivos bem definidos e recursos suficientes para poderem desenvolver as tarefas requeridas.
Já o PMBOK(2008) define: “Um projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo.” Para Kerzner (2002, p.44), “Trata-se de um empreendimento com objetivo identificável, que consome recursos e opera sob pressões de prazos, custos e qualidade. Alem disso, projetos são, em geral, considerados atividades exclusivas de uma empresa.”
Em relação aos papéis e responsabilidades relacionadas a projetos, programas e portfólios temos a figura do Sponsor, do Gerente de Projetos e dos Stakeholders. Para o PMBOK(2008). Sponsor é “pessoa ou o grupo que fornece os recursos financeiros, em dinheiro ou em espécie, para o projeto”. O Gerente de Projetos, por sua vez, é “a pessoa responsável pelo gerenciamento do projeto.” PMBOK(2008). No contexto de gerenciamento de projetos, Stakeholder é “qualquer grupo ou indivíduo que pode afetar ou é afetado pela realização dos objetivos da empresa” FREEMAN(1984, p. 25). Segundo o PMBOK(2008):
São pessoas e organizações, como clientes, patrocinadores, organizações executoras e o público, que estejam ativamente envolvidas no projeto ou cujos interesses possam ser afetados de forma positiva ou negativa pela execução ou término do projeto. Elas podem também exercer influência sobre o projeto e suas entregas.
Projetos, Programas e Portfólios necessitam de gerenciamento. Segundo o PMBOK(2008):
O gerenciamento de projetos é a aplicação de conhecimento, habilidades, ferramentas e técnicas às atividades do projeto a fim de atender aos seus requisitos. O gerenciamento de projetos é realizado através da aplicação e da integração dos seguintes processos de gerenciamento de projetos: iniciação, planejamento, execução, monitoramento e controle, e encerramento.
Como afirma Thiry(2000), gerenciamento de projetos tem como objetivo atingir a entrega de vários resultados com o mínimo de recursos possíveis, enquanto que a gerência de programas se concentra em conseguir o máximo de benefícios com os recursos disponíveis. Pode-se dizer que projetos focam na eficiência enquanto programas na eficácia e portfólios em alcançar o que fora definido no plano estratégico da empresa.
Estes gerenciamentos visam a atingir o sucesso dos projetos. Para KERZNER(2002, p.44) a explicação de sucesso é aquela que é mensurada em termos de fatores primários e secundários, sendo eles os primários: no prazo; dentro do orçamento; no nível desejado de qualidade e secundários: aceitação pelo cliente; o cliente concorda com a utilização de seu nome como referência. Já para o PMBOK(2008), sucesso em projetos é outorgar todos os entregáveis, conforme os planos de projetos, principalmente em relação a tempo, custo, escopo e qualidade.
O PMBOK(2008) define entregável como:
Qualquer produto, resultado ou capacidade para realizar um serviço exclusivos e verificáveis que devem ser produzidos para terminar um processo, uma fase ou um projeto. Muitas vezes utilizado mais especificamente com referência a uma entrega externa, que é uma entrega sujeita à aprovação do patrocinador ou do cliente do projeto.
Para atingir o sucesso não bastam os entregáveis. Os stakeholders precisam estar satisfeitos. Para tal se faz necessário gerenciá-los. De acordo com o PMBOK(2008)
O gerenciamento das partes interessadas se refere a satisfazer as necessidades das partes interessadas no projeto e resolver problemas com elas. O gerenciamento ativo das partes interessadas aumenta a probabilidade de o projeto não se desviar do curso por causa de problemas não resolvidos das partes interessadas, aumenta a capacidade das pessoas operarem em sinergia e limita as interrupções durante o projeto. Em geral, o gerente de projetos é o responsável pelo gerenciamento das partes interessadas.
Para melhor definir sucesso e fracasso em projetos, recorremos ao relatório publicado pelo THE STANDISH GROUP(1994). O mesmo não só publicou as taxas de fracasso e sucesso, mas também apontou os indicadores de sucesso e fracasso. Seu relatório original foi feito em 1994 e publicado como “the chaos report”. O THE STANDISH GROUP(1994) estudou 365 empresas com um total de 8.380 projetos de Sistema de Informação em desenvolvimento. O relatório resultante divide os projetos em três resultados distintos que chamaram Resoluções:
Resolução do tipo 1 “Projeto com Sucesso” Completou no tempo e orçamento, com todas as características e funções, conforme especificado. Apenas 16,2% dos projetos caíram nesta categoria.
Resolução do tipo 2 “Projeto Contestado” foram concluídos, mas excederam o custo, tempo, e / ou falta de características e funções que foram originalmente especificadas. 52,7% de todos os projetos estudados caíram nesta Resolução.
Resolução do tipo 3 “Projeto com Fracasso” Estes projetos foram abandonados ou cancelados em algum ponto e tornou-se assim perda total. 31,1% de todos os projetos estudados caíram nesta categoria.
Este estudo utilizará as três resoluções do THE STANDISH GROUP(1994) acima referidas, como resultado do projeto: um projeto bem sucedido deve ser concluído no tempo, no orçamento, e entregar qualidade (características e funções), como prometido no escopo. Qualquer coisa a menos será um projeto fracassado e/ou um projeto contestado.
Com base no relatório the chaos report pode-se salientar que apenas 16,2% dos projetos foram bem sucedidos em tempo, custo, escopo e qualidade, e que dos 70% de projetos que não foram bem sucedidos, mais de 52% eram falhas parciais e 31% foram completos fracassos. O que deve impulsionar os gerentes de projeto, tanto a reflexão quanto a motivação à ação.
Portanto, agora se tem informações sobre as taxas de sucesso e fracasso em projetos, mas, existem diferenciais significativas entre projetos bem-sucedidos e o que falharam? De acordo com o THE STANDISH GROUP(1994), existem.
Os cinco fatores mais encontrados em projetos de sucesso são:
Estes são os cinco mais elencados no relatório. O relatório conclui que estes foram os elementos que foram mais freqüentemente apontados como principais contribuintes para o sucesso do projeto. Mas, será que esses elementos por si só são uma garantia de sucesso? Jamais. Mas se estes são bem gerenciados, de acordo com o THE THE STANDISH GROUP(1994), terá uma probabilidade muito maior de alcançar o sucesso tão desejado.
Na próxima categoria “Contestado”, algum dos fatores tempo, custo, qualidade ou escopo não foram alcançados completamente. Logo, o sucesso pode ser contestado.
Os cinco fatores mais encontrados em projetos contestados são:
E, por ultimo, a lista de todos os fatores encontrados no relatório em relação a projetos fracassados.
Os dez fatores mais encontrados em projetos fracassados são:
Observa-se que nos três primeiros lugares para o resultado do projeto, o envolvimento do usuário é listado como o primeiro ou o segundo em cada um.
Em uma empresa multinacional da indústria óptica (líder em seu segmento) foram criados, simultaneamente, dois projetos pelo vice-presidente e diretor de operações da empresa. Nestes dois projetos, o mesmo foi o patrocinador ou Sponsor.
No termo de abertura de criação de cada um dos projetos, o Sponsor designou o mesmo gerente de projetos para ambos, com a responsabilidade pela gestão do tempo, custo, escopo e qualidade dos projetos.
O Sponsor repassou ao gerente de projetos a responsabilidade total sobre os projetos, com plenos poderes de alocação de recursos humanos, gestão dos recursos financeiros designados a cada um dos projetos, determinou que a infra-estrutura dos projetos fosse compartilhada e também estabeleceu um canal direto de comunicação entre ele e o Gerente de Projetos.
Um dos projetos denominado Pedido Eletrônico tinha como objetivo receber os pedidos de lentes e blocos através da internet. Sua justificativa era que, com a entrada dos pedidos via internet, haveria uma redução dos pedidos via telefone, reduzindo assim a digitação e por sua vez erros de digitação pelos operadores. Outro ponto considerado foi a diminuição do tempo de atendimento e entrada dos pedidos, uma vez que os mesmos seriam enviados diretamente pelo cliente, dispensando a utilização de um operador. Finalmente, redução no número de operadores de telemarketing de acordo com o aumento dos pedidos eletrônicos.
Suas premissas baseavam-se na idéia de que os clientes passariam a utilizar cada vez mais o pedido eletrônico, em vez de pedidos via fax ou telefone. Os gerentes comerciais e regionais da empresa utilizariam o sistema para aprovação do pedido. E o projeto possuía como restrição que os clientes e gerentes comerciais necessitariam de um computador conectado a internet.
O Pedido Eletrônico tinha como escopo:
Korper e Ellis (2001) definem extranet como uma rede privada que se utiliza da tecnologia da internet para compartilhar de forma segura informações ou operações de negócios com clientes, fornecedores, parceiros, representantes ou outro grupo de interesse.
Segundo Laudon(2004, p61) e Padoveze(2004, p68), ERP (Enterprise Resource Planning) ou SIGE (Sistemas Integrados de Gestão Empresarial, no Brasil) são sistemas de informação que integram todos os dados e processos de uma organização em um único sistema.
Quais os desafios do projeto?
O outro projeto foi denominado RemoteEdging e tinha como objetivo a leitura do formato de armações, a entrada da receita oftalmológica em uma ótica e o corte das lentes num laboratório, ambos remotos. Como justificativas do projeto, as óticas não necessitariam mais enviar as armações aos laboratórios para efetuar a leitura do formato, diminuindo assim o tempo e o custo com logística. Os laboratórios por sua vez poderiam atender mais clientes por causa da redução de tempo e logística com as leituras e também, aumentar o seu raio de atuação “distância”.
Para a empresa patrocinadora do projeto, a justificativa era a venda de novos equipamentos de leitura e corte, através do novo sistema, e a criação de uma base de dados de lentes cortadas da empresa ou de empresas concorrentes, gerando assim informações importantes que através de ferramentas de Bussines Inteligence (B.I.). A empresa poderia ter uma tomada de decisão e campanhas de marketing mais eficientes e eficazes.
Para este trabalho serão utilizadas duas definições metodológicas para Bussines Inteligence. Segundo Han e Kamber (2001, p. 5) BI é uma:
Área de estudo interdisciplinar, ligada à tecnologia da informação, que tem como objeto de estudo a elaboração (normativo) de sistemas de informação computacionais responsáveis por organizar grandes volumes de dados (data warehouse), facilitar a descoberta de relações entre tais dados (data mining; knowledge discovery in databases – KDD).
E, conforme Elmasri e Navathe (2000) “oferecer interfaces que facilitem ao usuário o entendimento das relações entre os dados (descritivo), a fim, por exemplo, de prover melhores informações para a tomada de decisão empresarial”.
A premissa do RemoteEdging seria a grande aceitação das óticas e laboratórios, já que o produto do projeto passa uma imagem de alta tecnologia e modernidade. Como restrição, as óticas e laboratórios teriam que adquirir novas máquinas para leitura e corte das lentes, terem acesso a internet para enviar e receber os pedidos, e funcionários capacitados para executar estas tarefas.
O escopo do RemoteEdging foi definido como:
A tecnologia utilizada em ambos os projetos na parte do site foi WebSphere, Java com DB2 na plataforma Linux.
No Pedido Eletrônico integração com o JDE (ERP da Empresa na época) e no RemoteEdging softwares desenvolvidos em Java com o armazenamento das informações em FlatFile.
Quais os desafios do projeto?
RemoteEdging:
Ao analisar superficialmente os projetos, tenciona-se a dizer que o RemoteEdging seria muito árduo ter sucesso, pois requer:
Já no Pedido Eletrônico o conceito de e-Commerce/E-Business já esta bem disseminado, teoricamente seria trocar a entrada de pedidos do papel para a internet.
No decorrer dos projetos o RemoteEdging apresentava grandes dificuldades em relação à comunicação entre o software desenvolvido e as máquinas. Em primeiro lugar foi necessário o aprendizado do protocolo de comunicação e apesar de seguir a risca o protocolo, a máquina não respondia de acordo com o esperado, além disso, ainda teria que ser feito o desenho do formato das lentes no software. Estas dificuldades estavam impactando na moral da equipe, no cronograma, nos custos, etc. Sendo assim, foram concentrados esforços em dois focos: motivar a equipe do projeto e dar recursos para superar a dificuldade. O Gerente de Projetos entrou em contato direto com o responsável pela programação das máquinas, que disse que bastava seguir o protocolo que tudo sairia bem. A equipe seguia o mesmo e não alcançava o resultado que o protocolo dizia. Após muita negociação interna e intervenção do Gerente de Projetos junto ao Sponsor, foi conseguida a dedicação de um tempo do desenvolvedor do protocolo, que é funcionário da matriz em outro país, para analisar a questão. Foi enviado o software para análise onde o mesmo funcionou sem problemas de comunicação com a máquina do desenvolvedor. Então foi constatado que a versão do protocolo que a empresa tinha nas máquinas não era a mais recente, após o recebimento da última versão e gravação na EPROM da máquina, tudo correu bem. Aproveitando o contato direto com o “pai da criança”, foi constatado que para desenhar o formato faz-se necessário a conversão de Radianos (R,α) para Gradius (X/Y) e o projeto deslanchou.
O Pedido Eletrônico estava caminhando muito bem, dentro do custo, prazo, qualidade e a equipe de projeto motivada. Houve levantamento do mesmo, análise e desenvolvimento de toda a parte de entrada do pedido, mas quando se chegou na hora de definição de uma regra de negócios para o prazo, desconto e a aprovação do pedido é que houve a grande surpresa. A diretoria comercial não tinha uma regra de negócio definida, e não tinha o mínimo interesse em definir um padrão, pois gerentes comerciais de mesmo nível tinham condições de pagamento e desconto diferenciados uns dos outros e um não poderia, de maneira alguma, tomar conhecimento de que o seu colega tinha este privilégio. Logo, como gerar uma regra de negócio que atenda a todos, sem o interesse da alta gerencia comercial? Por essa falta de interesse e comprometimento da área comercial em normatizar as regras de negócio, o sponsor resolveu cancelar o projeto. Uma vez que houve a inclusão de um novo programa no portfólio da empresa, programa este de migração do ERP da empresa de JDE para Oracle Application agendado para os próximos dois a três anos. Sendo assim, em médio prazo, a migração para esta nova plataforma tecnológica englobaria a solução de e-Commerce, o que incluiria a definição das regras de negócios. E o mesmo não precisaria utilizar da autoridade do cargo para forçar uma definição imediata, referentes à área comercial.
Segundo o conceito de Freeman e Reed (1983), as partes interessadas stakeholders afetam ou podem ser afetadas na consecução dos objetivos organizacionais, afetando também os objetivos do projeto, em suma seu escopo bem como seus entregáveis.
O “pulo do gato” é que projetos são desenvolvidos por pessoas e estas precisam estar envolvidas e comprometidas com o projeto. Dessa forma, a gerência dos stakeholders (partes interessadas) auxilia a análise, a definição da estratégia organizacional e, o escopo dos portfólios, programas e projetos da empresa, tratando da possibilidade de resultados benéficos para a organização em relação a essas partes – seus stakeholders. (WHITTINGTON, 2002).
O sucesso dos portfólios, programas e projetos da empresa, dependem de uma ótima relação com os stakeholders, já que a administração das relações com os mesmos é essencial ao longo prazo para o bom funcionamento das organizações (SENDER; FLECK, 2004).
O RemoteEdging, apesar ter que aprender e implementar muita tecnologia ao longo do projeto, todos os stakeholders estavam comprometidos com o projeto. Já no Pedido Eletrônico, nem todos estavam à área comercial não comprou o projeto e não queria modificar sua maneira de efetuar o negócio da empresa.
Portanto, foi constatado que tecnologia não é entrave, com talento, garra e determinação, podem-se quebrar barreiras tecnológicas.
O comprometimento de todos os stakeholders é de suma importância para o sucesso de um projeto. Pode-se perceber que o sucesso de um projeto depende do comprometimento destas pessoas. Para tanto, algumas recomendações podem ser feitas como envolver os stakeholders, trazendo-os para o projeto, firmando um comprometimento através da Gerência de Stakeholders. Se ainda assim os stakeholders não estiverem comprometidos faz-se necessária a intervenção do Sponsor. Caberá a ele envolvê-los o quanto antes ou decidir terminar o projeto.
COOPER, R. G., EDGETT, S. J. e KLEINSCHMIDT, E. J. Portfolio Management in New Product Development: Lessons from the Leaders – I. Research Technology Management, v.40, n.5, p.16-28, 1997.
DOBSON, Michael Singer. The juggler’s guide to managing multiple projects. Newton Square, Pennsylvania: Project Management Institute, 1999.
DYE, Lowell D.; PENNYPACKER, James S. Project portfolio management and managing multiple projects: two sides of the same coin? Proceedings, PMI, 2000.
ELMASRI, R.; NAVATHE, S. B. Fundamentals of database systems. 3ed. Addison-Wesley, 2000.
FREEMAN, R. E. Strategic management: A stakeholder approach. Boston: Pitman Publishing. 1984.
FREEMAN, R. E.; REED, D. L. Stockholders and stakeholders: a new perspective on corporate governance. California Management Review, California: ABI/Inform, v. 25, n. 3, p. 88-92, Spring 1983.
GLASER, B. & STRAUSS, A. The Discovery of Grounded Theory: Strategies for Qualitative Research, Chicago: Aldine. 1967
HAN, J., KAMBER, M. Data mining: concepts and techniques. Morgan Kaufmann Publishers, 2001.
INTERNATIONAL STANDARD ORGANIZATION. ISO 10006: Quality management – Guidelines to quality in project management. 1997.
KERZNER, Harold. Gestão de projetos: as melhores práticas. Porto Alegre: Bookman, 2002. 519p.
KORPER, S.; ELLIS, J. E-Commerce book: building the e-empire. 2. ed. San Diego: Academic Press, 2001. 299p.
LAUDON, Kenneth C. Sistemas de Informações gerenciais : administrando a empresa digital. São Paulo: Prentice Hall, 2004
MERRIAM, S. B. Qualitative research and case study applications in education. San Francisco: Jossey-Bass, 1998.
PADOVOZE, Clóvis Luís. Sistemas de informações contábeis: fundamentos e análise. São Paulo: Atlas, 2004
PROJECT MANAGEMENT INSTITUTE, PMI. Um Guia do Conjunto de Conhecimentos em Gerenciamentos de Projetos: Guia PMBOK. 4ed. Pennsylvania: Four Campus Boulevard, 2008.
STRAUSS, A.L.; Corbin, J. Basics of qualitative research: grounded theory procedures and techniques. London: SAGE Publications, 1990. 270p.
SENDER, G.; FLECK, D. L. Folga Organizacional e Gestão de Stakeholders: um estudo em bancos brasileiros. In: ENANPAD, 28., 2004, Curitiba/PR. Anais… Rio de Janeiro: Anpad, 2004. CD-ROM.
THE STANDISH GROUP(1994). The chaos report. http://www.standishgroup.com/sample_research/chaos_1994_1.php. visualizado em 16 de setembro de 2009.
THIRY, Michel. A learning loop for successful program management. Proceedings: Project Management Institute Seminar/Symposium (31st), Houston, Texas, 2000.
TUMAN, G.J. Development and Implementation of Effective Project Management Information and Control Systems, In: CLELAND, D. I.; KING, W, R. Project Management Handbook. Van Nostrand Reinhold, New York, 1983.
WHITTINGTON, R. O que é estratégia? São Paulo: Pioneira Thompson Learning, 2002.
YIN, Robert (1994). Case Study Research: Design and Methods. 2ª Ed. Thousand Oaks, CA: SAGE Publications.
Referência deste artigo para citação:
FERENHOF, H. A. . Stakeholders: fator determinante para o sucesso. In: 9o. Seminário Internacional de Gerenciamento de Projetos, 2009, São Paulo. Seminário Internacional de Gerenciamento de Projetos. São Paulo : PMI/SP, 2009.
Helio Ferenhof, Dr. Eng, MBA, PMP .'. ITIL Foundations Bacharel em ciência da computação pela UNESA; Mestre em Engenharia e Gestão do Conhecimento – UFSC. Doutor em Engenharia de Produção e Sistemas – UFSC. MBA em E-Business pela FGV/RJ; Professor da Pós-Graduação em Gerenciamento de Projetos e Segurança da Informação do SENAC/SC; Professor da Pós-Graduação em Gerenciamento de TI & Projetos da Universidade Estácio de Sá /SC; Diretor do IGCI empresa de consultoria em Gestão do Conhecimento, Gestão de Projetos & TI (www.igci.com.br) ; Apresenta mais de 20 anos de experiência adquirida em empresas multinacionais e consultorias de renome.
You must be logged in to post a comment.
2:45:22 pm
Caro Hélio.:
Interessante e verdadeiro o artigo.
Estou fazendo uma proposta para relacionar, organizar, priorizar e sugerir o gerenciamento dos Programas e Projetos do Portfólio de uma empresa, e o artigo trás idéias e sugestões que serão aproveitadas (com a devida citação).
UM TFA do
Pedro Lemos