Uma abordagem para Tailoring de processos de gestão de projetos de software baseado na Houston Matrix – Um estudo de caso

Autor: Rogério Afonso de Freitas - PMP

Resumo

Um dos grandes desafios encontrados por organizações que desenvolvem projetos é definir um critério para efetuar a adequação das melhores práticas e dos processos de gerenciamento de projetos descritos no PMBOK®. A questão central gira em definir como classificar os projetos para, baseado nessa classificação, efetuar a adequação, também conhecida como tailoring dos processos de gestão de projetos. Este artigo apresenta uma proposta de tailoring dos processos descritos no guia PMBOK® para a gestão de projetos de desenvolvimento software, baseado na Houston Matrix - uma abordagem de classificação de software proposta por Tood Little. O modelo proposto foi implementado em uma empresa nacional de médio porte – pioneira no Brasil em seu ramo de atuação - que têm seu negócio fortemente vinculado e dependente da introdução de novas tecnologias com o objetivo de obter uma melhor dinâmica em sua gestão de projetos de desenvolvimento softwares e uma maior assertividade de resultados em seus objetivos estratégicos e de negócios.

Introdução

O ambiente empresarial vem passando, nas últimas décadas, por intensas mudanças, reflexo das inúmeras transformações tecnológicas, sociais e políticas, em curso nos mais diversos setores econômicos. Surge daí, a necessidade de encontrar respostas e soluções para problemas inéditos, os quais nunca foram enfrentados anteriormente e que possivelmente, possam ser tão exclusivos, que nunca voltem a se repetir no futuro. Conceitos como eficiência, eficácia e produtividade passam a ser perseguidos com maior intensidade e paralelamente, com maior dificuldade.
Desta forma, as organizações buscam novas formas de gestão para melhorar a competitividade. Surge à necessidade de lançamento de novos produtos, criação de novos serviços. As organizações passam a ter necessidade de suporte ágil, implementação de mudanças em seus processos, produtos e negócios.
Segundo Valeriano (2001, p. 30), o gerenciamento estratégico e administração por projetos são opções para apoio as decisões e gerenciamento de mudanças, por exemplo, criação de um produto, processo e serviço.
A gerência de projetos tem cada vez mais se tornado um assunto de grande importância para as organizações e para sua capacidade de sobrevivência (DINSMORE, 2005). O mundo está numa era de muitas mudanças, como a globalização do mercado, acirramento da concorrência e evolução tecnológica, o que torna o gerenciamento de projetos de forma eficiente um dos grandes desafios para os executivos modernos (KERZNER, 2006).
É nítida a importância das atividades que se caracterizam pela inovação em qualquer processo de mudança, pois, em geral, são elas que agregam mais valor ao produto ou serviço. Neste sentido, gerenciar melhor os recursos dos projetos, para obter sucesso é fundamental para as empresas que querem ser mais competitivas e progredir. No entanto, conseguir estabelecer uma correta adequação de processos, em um ambiente onde coexistem projetos de diversos tamanhos e complexidade, ainda é um grande desafio para muitas organizações.
Neste contexto, o que se busca neste artigo, é apresentar uma proposta de adequação (tailoring) dos processos descritos no guia PMBOK® para a gestão de projetos de desenvolvimento software utilizando metodologias ágeis, baseados na abordagem de classificação de software proposta por Little (2005). O modelo de tailoring proposto foi implementado por uma empresa nacional de médio porte – pioneira no Brasil em seu ramo de atuação e que têm seu negócio fortemente vinculado e dependente da introdução de novas tecnologias - encaixando-se perfeitamente no cenário competitivo descrito no início deste artigo - com o objetivo de obter uma melhor dinâmica em sua gestão de projetos de desenvolvimento softwares que oferecem suporte a suas operações e uma maior assertividade de resultados em seus objetivos estratégicos e de negócios.

Estrutura do artigo

O presente artigo apresenta-se organizado da seguinte maneira: o item 2 revisa, rapidamente, conceitos de gestão de projetos e as melhores práticas de gerenciamento de projetos definidos pelo PMI® no guia PMBOK®; o item 3 apresenta a abordagem de classificação de projetos de software, proposto por Little (2005), denominado de Houston Matrix; o item 4 contextualiza o ambiente da empresa objeto do estudo e utilizando como exemplo os projetos de software da mesma, exemplifica a aplicação da Matriz Houston e a classificação dos projetos; o item 5 apresenta a adequação (tailoring) dos processos descritos no guia PMBOK®, utilizados para os diferentes projetos de software da empresa, com base na classificação obtida com a Houston Matrix; e finalmente, o item 6 consiste em uma breve conclusão.

Processos de Gerenciamento de Projetos baseados no PMBOK® 

O PMBOK® lista ao todo, 42 processos de gerenciamento de projetos divididos nos cinco grupos de processos de gerenciamento de projetos e nas nove áreas de conhecimento em gerenciamento de projetos. O Quadro 1 apresenta o mapeamento dos 42 processos entre os cinco grupos de processos e as nove áreas de conhecimento.  
Para cada área do conhecimento e grupo de processos, o PMBOK® sugere o uso de entradas, ferramentas e técnicas para gerar saídas, que num processo iterativo, servem de entrada para os processos de outras áreas do conhecimento, com o objetivo de obter sucesso no gerenciamento de projetos.  A Tabela 1 totaliza as entradas, ferramentas e técnicas e saídas manipuladas no gerenciamento de um projeto.
Ao analisar a tabela 1, nota-se que o número de artefatos utilizados nos processos de gerenciamento de um projeto é elevado e demanda um grande esforço de gestão. Somando-se todas as entradas, ferramentas, técnicas e saídas possíveis de serem utilizadas em nove áreas do conhecimento, constata-se que podem chegar a 520 o número de artefatos a serem manipulados durante o ciclo de vida do projeto. Se existirem inúmeras fases durante o ciclo de vida do projeto, o arcabouço de processos de gerenciamento torna-se exponencial e pode ser representado como:

É perceptível que não é adequado utilizar todas as boas práticas e processos descritos no PMBOK® em qualquer projeto. Pequenos projetos, por exemplo, teriam sua duração e custo ampliados por conta do excesso de processos adotados em sua gestão, tornando-os por vezes inviáveis economicamente ou por conta da perda do time to market.

Tabela 1 – Totalização de entradas, ferramentas, técnicas e saídas por área de conhecimento definidas no PMBOK®

Em fato, o Guia PMBOK® enfatiza que existe um consenso que o uso das boas práticas possa “aumentar as chances de sucesso de uma ampla gama de projetos” (PMBOK, 2008), mas enfatiza a necessidade de tailoring dos processos ao citar que “[...] gerentes de projetos e suas equipes devem abordar com cuidado cada processo e as entradas e saídas que o constituem. [sic] Esse esforço é conhecido como adequação” (PMBOK, 2008, p. 38).

Quadro 1 - Mapeamento entre processos de gerenciamento de projetos, grupos de processos de gerenciamento de projetos e as áreas de conhecimento. Fonte: Adaptado do PMBOK (2008, p.43

Um questionamento comum, diante da constatação da necessidade de executar o tailoring de processos para projetos é: quais critérios utilizar para classificar diferentes projetos e definir o conjunto de processos mais adequado para cada tipo de projeto?

Em projetos de desenvolvimento de software essa classificação se torna ainda mais difícil, diante do elevado número de variáveis envolvidas, tais como arquitetura do software, tecnologias envolvidas, impacto para os negócios, inovação, complexidade, incerteza, criticidade do software para as operações do negócio, entre outras.
Uma opção, proposta neste artigo, é o uso da Houston Matrix de Little (2005) para classificar os diferentes tipos de projetos de software e efetuar o tailoring dos processos de gestão de projetos.

Classificação de projetos segundo a Houston Matrix

A Houston Matrix é uma abordagem proposta por Little (2005), para classificar projetos de software de acordo com sua incerteza e complexidade, através de um modelo de pontuação com sua respectiva plotagem em uma matriz composta por quatro quadrantes, a saber:

• “Dogs” (Cachorros): projetos simples com baixa incerteza;
• “Colts” (Potros): projetos simples com grande incerteza;
• “Cows” (Vacas): projetos complexos com baixa incerteza;
• “Bulls” (Touros): projetos complexos com grande incerteza.

Little (2005) define os atributos de complexidade e incerteza que serão tabulados para definir o tipo em que o projeto se enquadra.  A tabela 2 apresenta os atributos de complexidade e a tabela 3 os atributos de incerteza.
Para Little (2005, p.2), a estrutura de um projeto determina sua complexidade.  Com base nisto, elaborou um sistema para ranquear a complexidade de um projeto baseado nos atributos:

• Tamanho da equipe;
• Criticidade da missão;
• Localização do time;
• Capacidade do time;
• Conhecimento do domínio;
• e dependências.

Tabela 2 – Atributos de Complexidade e sua pontuação (Complexidade mínima = 1, complexidade máxima = 10).

Fonte: Baseado em (tradução livre) de Little (2005, p.2)
E as incertezas de um projeto estão relacionadas às condições do mercado e restrições do projeto. Os indicadores primários de incerteza são:

• Incertezas de mercado;
• Incertezas Técnicas;
• Duração do Projeto;
• Dependências do projeto com outros projetos;
• Escopo Flexível.

No modelo de Little (2005), a totalização da pontuação é calculada com base na agregação da pontuação dos atributos de complexidade e incerteza:

Complexidade = 2Σ log10 xi | Incerteza = 2Σ log10 yj

Onde i e j são respectivamente, atributos de complexidade e incerteza de um determinado projeto e xi e ji são as pontuações individuais de complexidade e incerteza conforme descrito nas tabelas 2 e 3. O log x dos termos representa a dimensão das informações avaliadas.  A equação equivale a re-escalar cada atributo entre 1 e 2 e em seguida, efetuar o produto.

Tabela 3 – Atributos de Incerteza e sua pontuação (incerteza mínima = 1, incerteza máxima = 10).

Baseado em (tradução livre) de Little (2005, p.3)
De acordo com o tipo de cada projeto, Little sugere uma abordagem em metodologia de desenvolvimento de software. A figura 4 sumariza cada quadrante da Houston Matrix e suas principais características:

Figura 4 – Houston Matrix – avaliação de quadrantes (Little, 2005, p. 31)

Nota-se que os projetos classificados como “Dogs” (Cachorros), são projetos bastante simples, de produtos com alto grau de maturidade e com baixo grau de incerteza e complexidade e que demandam pequenas equipes, projetos “Colts” (Potros) são projetos simples, que demandam agilidade e times pequenos, projetos “Cows” (Vacas) apesar de complexos, estão inseridos em ambientes maduros e demandam interfaces definidas, enquanto que os projetos “Bulls” (Touros) são projetos que demandam agilidade para lidar com seu alto grau de incerteza e forte definição de processos para gerenciar sua complexidade.

Apesar de o objetivo de Little para a Houston Matrix fosse classificar projetos para definir processos de engenharia de software, na empresa X optou-se por utilizá-la também para efetuar o tailoring de processos de gestão de projetos.

Tailoring de processos de gerenciamento de projetos baseados nos quadrantes da Houston Matrix – estudo de caso

A adequação dos processos de gerenciamento de projetos, com base na classificação obtida pelo uso da Houston Matrix, foi implementada em uma empresa nacional de médio porte, denominada de empresa X.  A empresa em estudo foi fundada em novembro de 2002, teve o início de suas operações comerciais no 2º trimestre de 2004, tendo cinco anos e meio de operação. Atua no setor de distribuição e veiculação de mídia digital e na venda de espaço publicitário de mídia digital . O core dos negócios da empresa X é altamente dependente de tecnologias (hardware e software). A empresa X, adota uma gestão corporativa bastante informal e um organograma com poucos níveis. O nicho em que a empresa atua é bastante recente, e devido a isso, não existe um modelo de negócios consolidado que sirva de benchmarking. Dessa forma, as regras de negócio a serem implementadas nos projetos de software a serem desenvolvidos, sofrem alterações freqüentes e em intervalos curtos de tempo, muitas vezes essas regras são modificadas durante o refinamento dos requisitos dos softwares.
No período estudado, a empresa X possuía uma pequena equipe fixa composta por 6 colaboradores: 1 (um) gerente de TI, 1 (um) gerente de P&D (Pesquisa e Desenvolvimento) que também atua como engenheiro de software, 1 (um) gerente de projetos, 1 (um) DBA e 2 (dois) analistas programadores, além de contratar recursos pontuais para participarem de projetos. O portfólio de projetos contempla 12 projetos sendo executados em paralelo.
Devido a essas características, a área de TI (Tecnologia de Informação) da empresa X, utiliza na maioria dos projetos, métodos ágeis de desenvolvimento de software como o FDD e em alguns casos, práticas de UP. O uso de métodos ágeis imprimiu agilidade ao desenvolvimento de software, mas criou a necessidade de um modelo de gestão de projetos, para melhorar o sucesso dos projetos.  Ao mesmo tempo, identificou-se que devido ao reduzido número de recursos disponíveis, era necessário adequar (tailoring) os processos de gestão de projetos.
Utilizando a Houston Matrix, classificaram-se os projetos, conforme demonstrado na figura 6. Pelos resultados mostrados na Matriz, percebe-se que:

• 6 dos 12 projetos (50%) estão no quadrante “Dog”;
• 2 projetos (17%) estão no quadrante “Colt”;
• 1 projeto (8%) está no quadrante “Cow”;
• 3 projetos (25%) estão no quadrante “Bull”.

Figura 5 – Matriz Incerteza x Complexidade: Projetos da empresa X

Para os projetos “Dogs”, definiu-se um conjunto de 27 processos de gestão de projetos, conforme demonstrado no quadro 2. Para os projetos “Colts”, “Cows” e “Bulls”, propõem-se uma abordagem incremental de processos.

Área do Conhecimento	Processos	Total Processos
Integração	Desenvolver o Termo de Abertura do Projeto	4
	Desenvolver o plano de gerenciamento do projeto
	Monitorar e controlar o trabalho do projeto
	Encerrar o projeto ou fase
Escopo	Coletar Requisitos	3
	Criar EAP
	Verificar o escopo
Tempo	Controlar o cronograma	6
	Definir as atividades
	Desenvolver o cronograma
	Estimar as durações das atividades
	Estimativa de recursos da atividade
	Sequenciar as atividades
Custo	Controlar os custos	2
	Determinar o orçamento
Qualidade	Realizar o Controle da Qualidade	1
Recursos Humanos	Contratar ou Mobilizar a equipe do Projeto	2
	Gerenciar a equipe do Projeto
Comunicação	Distribuir as informações	5
	Gerenciar as expectativas das partes interessadas
	Identificar as partes interessadas
	Planejar as comunicações
	Reportar o desempenho
Riscos	Identificação dos riscos	3
	Análise qualitativa
	Monitorar e controlar os riscos
Aquisições	Conduzir as aquisições	1
Total geral		27

Quadro 2 – Resumo de processos de gestão de projetos de projetos classificados como “Dogs”.

Devido a características dos projetos “Dogs” - projetos simples, de produtos com alto grau de maturidade, baixo grau de incerteza e complexidade, pequenas equipes, são necessários poucos processos de gerenciamento de qualidade, recursos humanos e riscos. Processos como planejamento da qualidade e garantia da qualidade podem ser reaproveitados de projetos anteriores (ativos organizacionais) e o foco passa a ser no processo de controle da qualidade. Os processos de gerenciamento de riscos são reduzidos e focam na análise qualitativa dos riscos devido ao baixo grau de incerteza dos projetos “Dogs”. No caso da empresa X, os projetos Dogs são executados em sua maioria pela equipe interna, tornando desnecessários os processos de aquisição. Como eventualmente é necessário a contratação de consultores externos, foi mantido 1 (um) processo de aquisição: Planejar Contratações.
Para os projetos “Colts”, devido a suas características muito próximas as projetos “Dogs”, definiram-se um conjunto de 29 processos conforme demonstrado no quadro 3.

Área do Conhecimento	Processos	Total Processos
Integração	Desenvolver o Termo de Abertura do Projeto	5
	Desenvolver o plano de gerenciamento do projeto
	Monitorar e controlar o trabalho do projeto
	Realizar o controle integrado de mudanças
	Encerrar o projeto ou fase
Escopo	Definir o escopo	3
	Criar a EAP
	Verificar o escopo
Tempo	Definir as atividades	6
	Sequenciar as atividades
	Estimativa de Recursos da atividade
	Estimar as durações das atividades
	Desenvolver o cronograma
	Controlar o cronograma
Custo	Determinar o orçamento	2
	Controlar os custos
Qualidade	Realizar o Controle da Qualidade	1
Recursos Humanos	Contratar ou Mobilizar a equipe do Projeto	2
	Gerenciar a equipe do Projeto
Comunicação	Distribuir as informações	5
	Gerenciar as expectativas das partes interessadas
	Identificar as partes interessadas
	Planejar as comunicações
	Reportar o desempenho
Riscos	Identificar os riscos	4
	Realizar a análise qualitativa dos riscos
	Monitorar e controlar os riscos
	Planejamento de respostas a riscos
Aquisições	Conduzir as aquisições	1
Total geral		29

Quadro 3 - Resumo de processos de gestão de projetos de projetos classificados como “Colts”

Nos projetos “Colts”, faz-se uso de todos os processos dos projetos “Dogs” incrementando-o com o uso de mais 2 (dois) processos: O processo de controle integrado de mudanças na área de conhecimento de integrações e o processo de planejamento de repostas a riscos na área de conhecimento de riscos.
Para os projetos classificados como “Cows”, definiu-se um número superior de processos, totalizando 34. Houve aumento de processos em uso para a gestão de projetos “Cows” nas áreas do conhecimento de Integração, Escopo, Qualidade, Recursos humanos e Aquisições (quadro 4).

Área do Conhecimento	Processos	Total Processos
Integração	Desenvolver o Termo de Abertura do Projeto	6
	Desenvolver o plano de gerenciamento do projeto
	Monitorar e controlar o trabalho do projeto
	Orientar e gerenciar a execução do projeto
	Realizar o controle integrado de mudanças
	Encerrar o projeto ou fase
Escopo	Coletar requisitos	5
	Criar a EAP
	Definir o escopo
	Controle do escopo
	Verificar o escopo
Tempo	Definir as atividades	6
	Sequenciar as atividades
	Estimativa de recursos da atividade
	Estimar as durações das atividades
	Desenvolver o cronograma
	Controlar o cronograma
Custo	Determinar o orçamento	2
	Controlar os custos
Qualidade	Realizar a garantia da Qualidade	2
	Realizar o Controle da Qualidade
Recursos Humanos	Contratar ou Mobilizar a equipe do projeto	3
	Desenvolver a equipe do projeto
	Gerenciar a equipe do projeto
Comunicação	Distribuir as informações	4
	Gerenciar as expectativas das partes interessadas
	Planejar as comunicações
	Reportar o desempenho
Riscos	Identificar os riscos	4
	Realizar a análise qualitativa dos riscos
	Monitorar e controlar os riscos
	Planejamento de respostas a riscos
Aquisições	Planejar as aquisições	2
	Conduzir as aquisições
Total geral		34

Quadro 4 - Resumo de processos de gestão de projetos de projetos classificados como “Cows”

Eventualmente, os projetos “Cows”, podem requerer o uso de mais processos da área de conhecimento de aquisições, como por exemplo, os processos de solicitar respostas de fornecedores, seleção de fornecedores, administração de contratos e encerramento de contratos, caso o projeto demande a aquisição de produtos, insumos ou a terceirização de parte do escopo do projeto. Os projetos da empresa X, classificados como “Cows”, não possuíam esses requisitos e esses processos de aquisições não foram necessários, por isso, não são listados no quadro resumo.
Já os projetos classificados como “Bulls”, utilizam-se de praticamente todos os processos de gestão de projetos descritos no PMBOK® (quadro 5).

Área do Conhecimento	Processos	Total Processos
Integração	Desenvolver o Termo de Abertura do Projeto	6
	Desenvolver o plano de gerenciamento do projeto
	Monitorar e controlar o trabalho do projeto
	Orientar e gerenciar a execução do projeto
	Realizar o controle integrado de mudanças
	Encerrar o projeto ou fase
Escopo	Coletar requisitos	5
	Criar a EAP
	Definir o escopo
	Controle do escopo
	Verificar o escopo
Tempo	Definir as atividades	6
	Sequenciar as atividades
	Estimativa de recursos da atividade
	Estimar as durações das atividades
	Desenvolver o cronograma
	Controlar o cronograma
Custo	Estimar os custos	3
	Determinar o orçamento
	Controlar os custos
Qualidade	Planejar a qualidade	3
	Realizar a garantia da qualidade
	Realizar o controle da qualidade
Recursos Humanos	Contratar ou Mobilizar a equipe do projeto	4
	Desenvolver a equipe do projeto
	Desenvolver o plano de recursos humanos
	Gerenciar a equipe do projeto
	Distribuir as informações	5
	Identificar as partes interessadas
	Gerenciar as expectativas das partes interessadas
	Planejar as comunicações
	Reportar o desempenho
Riscos	Planejar o gerenciamento dos riscos	6
	Identificar os riscos
	Realizar a análise qualitativa dos riscos
	Realizar a análise quantitativa dos riscos
	Monitorar e controlar os riscos
	Planejamento de respostas a riscos
	Monitorar e controlar os riscos
Aquisições	Planejar as aquisições	4
	Conduzir as aquisições
	Administrar as aquisições
	Encerrar as aquisições
Total geral		42

Quadro 5 - Resumo de processos de gestão de projetos de projetos classificados como “Bulls”
O uso desta abordagem na empresa X permitiu que a mesma fizesse um uso racional de seus recursos de gestão de projetos, dando maior foco na gestão dos projetos mais complexos sem com isso comprometer a gestão dos projetos considerados menos complexos. Apesar do uso recente desta abordagem (pouco mais de 1 ano), o uso desta abordagem já apresenta alguns resultados positivos, como uma maior assertividade nos términos dos projetos “Dogs” e “Colts”, 4 (quatro) projetos “Dogs” e 1 projeto “Colt” foram encerrados no prazo e custo planejados, bem como um melhor controle e satisfação dos stakeholders com os resultados parciais dos projetos “Cows” e “Bulls”. O uso desta abordagem também se apresentou como uma forma de comunicar a toda a organização uma ordem de grandeza dos projetos em desenvolvimento.

Considerações Finais

O uso da Houston Matrix de Todd Little apresenta uma perspectiva diferenciada para classificar projetos de desenvolvimento de software fazendo uso de critérios de incerteza e complexidade, permitindo a análise para definir métodos mais adequados para o processo de engenharia de software.

Utilizar a classificação dos softwares pela Houston Matrix para efetuar o tailoring de processos e definir um conjunto de artefatos sem declinar por completo de nenhum dos 42 processos do guia PMBOK®, apresentou-se como uma abordagem inovadora.

O uso desta abordagem na empresa X ainda é recente (pouco mais de 1 ano), mas já mostra resultados positivos, pois permitiu que a reduzida equipe interna adequasse o nível de esforço de gestão em projetos “Dogs” e “Colts” e focasse esforços nos projetos classificados como “Cows” e “Bulls”. Identificou-se também que a percepção de qualidade, alcance de metas e resultados, e a satisfação dos stakeholders teve um aumento significativo.

A inclusão de uma terceira dimensão na Houston Matrix, que considerasse a relevância do projeto para a empresa seria uma contribuição futura adicional, que poderia ampliar a abordagem proposta neste artigo.

Notas:

Este termo também se refere à customização ou tailoring dos processos – Guia PMBok® Quarta Edição p. 38

PMBok® - Project Management Body of  Knowledge, é um Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos, elaborado pelo PMI – Project Management Institute. Atualmente, encontra-se na 4ª. Edição, sendo uma referência de melhores práticas para o gerenciamento de projetos.

Todd Little, mestre em engenharia petrolífera pela University of Houston, é gerente sênior de desenvolvimento da empresa Landmark Graphics, Houston, USA. É membro do corpo diretivo da Agile Alliance, membro da IEEE Computer Society e membro da Society of Petroleum Engineers.

Devido à idéia original ter derivado da “Boston Matrix”, matriz desenvolvida pelo Boston Consulting Group, Little apelidou sua matriz de “Houston Matrix”.

Time to market – Quantidade de tempo que leva para desenvolver um novo produto, a partir de uma idéia inicial ou para o início de vendas de um novo produto ao mercado consumidor.

Todd Little utilizou-se dos princípios matemáticos definidos por C.E.Shannon, descritos no artigo “A Mathematical Theory of Communication”, publicada no Bell System Tech Journal em 1948, vol. 27, páginas 379-423 e 623-656.

Little defende o uso de métodos ágeis de desenvolvimento de software. Apesar da estreita relação entre a Houston Matrix e a definição da abordagem da metodologia de engenharia de software, esse assunto não será tratado em profundidade neste artigo.

Por questões de confidencialidade, o nome da empresa objeto deste estudo de caso, foi omitido.

Benchmarking é a busca das melhores práticas na indústria que conduzem ao desempenho superior. É visto como um processo positivo e pró-ativo por meio do qual uma empresa examina como outra realiza uma função específica a fim de melhorar como realizar a mesma ou uma função semelhante.

FDD - Feature Driven Development (Desenvolvimento Guiado por Funcionalidades) é uma metodologia ágil para gerenciamento e desenvolvimento de software, criada em 1997 num grande projeto em Java para o United Overseas Bank, em Singapura. Foi inicialmente publicada em 1999, no capítulo 6 do livro "Java Modeling in Color with UML", de Peter Coad, Eric Lefebvre e Jeff De Luca

UP - Unified Process (Processo Unificado) é um framework iterativo e incremental para o desenvolvimento de software. A primeira publicação a descrever o processo foi "The Unified Software Development Process", publicado em 1999 por Ivar Jacobson, Grady Booch e James Rumbaugh.

Stakeholder ou, em português, parte interessada ou interveniente, refere-se a todos os envolvidos num processo, por exemplo, clientes, colaboradores, investidores, fornecedores, comunidade etc. O processo em questão pode ser de caráter temporário (como um projeto) ou duradouro (como o negócio de uma empresa ou a missão de uma organização sem fins lucrativos).

Referências:

DINSMORE, Paul C. Como se tornar um profissional em gerenciamento de projetos: livro base de “Preparação para Certificação PMP – Project Management Professional”. Rio de Janeiro: Qualitymark, 2005.

KERZNER, Harold. Gestão de projetos: as melhores práticas. 2. ed. Porto Alegre: Bookman, 2006.

LITTLE, Todd.  Context-Adaptive Agility: Managing Complexity and Uncertainty, IEEE Software Magazine, May/June 2005, p. 28-35.

PMI, Project Management Institute, Inc. Guia PMBOK: Um Guia do Conhecimento em Gerenciamento de Projetos, 4ª Edição. Pennsylvania - USA: PMI, 2008.

RABECHINI, Roque Júnior; PESSÔA, Marcelo Schneck de Paula. Um modelo estruturado de competências e maturidade em gerenciamento de projetos. Revista Produção, Jan/Abr 2005, v. 15, n. 1, p. 034-043.

VALERIANO, Dalton L. Gerenciamento Estratégico e Administração por Projetos. São Paulo: Makron Books, 2001.

Sobre o autor:

 

Rogério Afonso de Freitas, PMP. Bacharel em Sistemas de Informação (Mackenzie – SP), MBA em Gestão de Negócios e Projetos, Pós-Graduado em Gerenciamento de Projetos pelo Instituto Brasileiro de Tecnologia Avançada – IBTA. Possui larga experiência em projetos de TI, notadamente em projetos de desenvolvimento de Software. Atua como gestor de TI e Gerente de Projetos em diversas organizações. Leciona Gerenciamento de Projetos entre outras disciplinas, na Universidade Nove de Julho em São Paulo/SP. Certificado PMP® e associado ao PMI®.

e-mail do autor: rfreitas@full4it.com.br