Blog CMMI & MPS.BR

Como é de conhecimento comum, um dos elementos chave para o sucesso de um projeto é a elaboração de um bom WBS (work breakdown structure ou em portugues, EAP). Com um bom WBS podemos controlar de forma mais efetivas os itens da tripla restrição (tempo, escopo e custo), mas ai vem aquela velha pergunta, até onde devemos decompor a WBS?

Devemos decompor a WBS em pacotes de trabalho até um nível que seja fácil de se gerenciar, mas… até que nível? Existem várias técnicas, várias regras, alguns gerentes recomendam pacotes de uma semana, 40 horas, 80 horas, 8 horas e outros. Enfim, não há uma regra definida, isso vai depender muito do tamanho, criticidade ou tipo do projeto, enfim… como será se controle.

Eu particularmente gosto de usar pacotes pequenos na maioria das vezes, especialmente em projetos mais críticos.

Cada pacote de trabalho deve ter:

• Esforço
• Prazo
• Responsável
• Custo
• Métrica que indique qualidade

Essa é uma boa forma de limitar sua WBS. Uma outra dica é sempre que tiver um pacote de trabalho faça as seguintes perguntas:

• Tem um responsável?
• O esforço foi estimado (ou da pra estimar)?
• Tem custo (ou da pra estimá-lo)?

Se todas essas perguntas tiverem resposta você pode continuar a decompor, caso contrário você pode parar e retornar ao nível superior.

Além disso você deve verificar a periodicidade com que o controle do projeto será realizado pois se você vai controlar suas baselines de custo, tempo e escopo mensalmente, qual o sentido de decompor os pacotes até o nível de horas? Por isso você deve ter em mente que a WBS não tem tamanho pré-fixado, mas dependerá do porte do seu projeto.

A ultima dica é que o custo para se gerenciar um pacote óbviamente não deve ser maior que o mesmo (nem metade ou 20% – sugiro no máximo 10%), afinal, o WBS deve nos ajudar no gerenciamento e não criar mais burocracia.

Muita gente acredita que “Código de Ética e de Conduta Profissional” seja uma das disciplinas do PMBOK. Estão enganados, pois não é! As nove disciplinas contidas no PMBOK são: gerenciamento do escopo, de riscos, de custos, da comunicação, dos recursos humanos, do tempo, da qualidade, de aquisições e gerenciamento da integração.

Em um primeiro momento, o fato do tema “Código de Ética e de Conduta Profissional” estar fora do PMBOK poderia causar entranheza ou algum tipo de desconforto aos leitores mal avisados, pois permite uma equivocada e precipitada conclusão de que o PMI estaria atribuindo baixa prioridade para assunto tão importante.Indiscutivelmente, a ética permeia todas as atividades de um gerente de projetos, para qualquer tipo de projeto, em qualquer uma das nove disciplinas mencionadas.

Na realidade, a ética está presente (ou deveria estar) no dia a dia de todas as pessoas, no exercício de nossas atividades profissionais ou pessoais, na escola, no trabalho, no clube, no trânsito, nos negócios, no cinema, na rua, enfim, a ética deveria ser o oxigênio levado a cada célula do organismo humano, dando-lhe vitalidade, saúde moral e direcionando as ações de empresários, políticos e cidadãos.

Retomando o tema de gerenciamento de projetos, em todas as nove áreas do conhecimento (disciplinas), a ética está presente. Por exemplo, no gerenciamento da comunicação, cabe ao gerente do projeto: elaborar/acompanhar o Plano de Comunicação do Projeto e distribuir a informação para os interessados no projeto. No entanto, é inerente à sua atuação nesta disciplina que ele seja ético, dizendo a verdade e sem postura de “omissão por conveniência” diante de situação desfavorável do projeto ou de seus resultados. De forma análoga, é responsabilidade do gerente de projeto no gerenciamento do escopo realizar a gestão dos requisitos do projeto, garantindo a entrega com qualidade nos prazos pactuados. Entretanto, do ponto de vista ético, o gerente deve deixar explícito, claro e documentado “o que o projeto faz e o que o projeto não faz”, evitando situações intencionalmente dúbias ou omissas. Há impasses em que muitos profissionais visando postergar a situação-problema alegam que “depois o cavalo fala…”.

Veja o post completo →

Em 1986 foi publicado um paper comparando a construção de pontes com a construção de software, como premissa foi utilizado:

• Pontes normalmente são entregues no prazo, dentro do orçamento e “não caem”
• Softwares raramente são entregues no prazo ou dentro do orçamento. E normalmente eles tem bugs.

Uma das maiores razões para o sucesso na construção de pontes é o alto nível de detalhe “em momento de design”. O “design” é congelado e o contratante tem pouquíssima flexibilidade de mudanças. Todavia, no mundo de negócios atual, este “congelamento” pode não acomodar as mudanças de negócio necessárias pelas empresas. Portando, um modelo mais flexível deve ser aplicado.

Mas também há outro elemento primordial a ser analisado entre a construção de pontes e construção de software. A construção de pontes é feita a pelo menos 3.000 anos. Quando uma ponte caia, as causas da queda eram investigadas, documentadas e disseminadas para que ninguém cometesse o mesmo erro novamente. Isto raramente acontece no desenvolvimento de software, onde as falhas são muitas vezes tratadas como causas normais e rotineiras e em sua grande maioria, são ignoradas. Como resultado, continuamos a cometer os mesmos erros que tínhamos na década passada (muda a linguagem ou o dispositivo, mas o erro é o mesmo).

Neste sentido, o foco da pesquisa do The Standish Group foi identificar:

• As falhas dos projetos de software
• Os maiores fatores que influenciam na falha de projetos de software
• Os pontos chave que podem reduzir estas falhas

Os Estados Unidos gastam mais de 250 bilhões de dólares cada ano no desenvolvimento de aproximadamente 175.000 projetos de software. O custo médio de um projeto em uma grande empresa americana é de 2.3 milhões de dólares, para uma empresa média é de 1.4 milhões d dólares e 434 mil dólares para uma empresa pequena. E a grande maioria destes projetos falha. Os projetos de desenvolvimento de software estão no caos.

O estudo classificou os projetos em três tipos:

• Sucesso: Projeto dentro do prazo, dentro do orçamento e com boa parte do escopo
• Sucesso parcial: Projeto funcionando, mas entregue sem atender ou custo, ou esforço ou com o escopo parcial
• Fracassos: Projetos cancelados ou não utilizados

Sua última revisão (2009) mostrava que:

• 24% dos projetos fracassam
• 44% dos projetos são entregues com sucesso parcial
• E apenas 32% dos projetos obtêm sucesso.

Veja o post completo →

O PMI Chapter São Paulo tem o prazer de apresentar a comunidade de gerenciamento de projetos, o trabalho realizado de aplicação de uma verificação de maturidade organizacional utilizando o OPM3.

Partindo do princípio que há maturidade em gerenciamento de projetos como parte da estratégia da empresa e por outro lado há também a maturidade em gerenciamento de projetos garantindo a estratégia da empresa, foi possível obter uma visão geral sobre Maturidade em Gerenciamento de Projetos com foco no OPM3 e como aplicar, passo a passo, o OPM3 nas empresas.

O evento mostrará como foi realizado esse trabalho desde a viabilização financeira da aquisição da ferramenta, passando pela criação da equipe de projetos formada pelos voluntários do PMI SP, até a aplicação nas diretorias do PMI SP e a conclusão do trabalho.

A palestra será realizada dia 17.jul no SENAC Campinas da rua Sacramento e há um custo de R$ 30,00 para associados e R$ 50,00 para não associados ao PMI.

Para se inscrever acesse www.pmisp.org.br, clique no link “Educação” em seguida “Eventos” ou ligue para 11.5041.4144.

Pessoal da região de Campinas, corra pois o evento já é este sábado.

O objetivo deste post é apresentar os principais elementos que um bom plano de projeto deve ter. Não existe um modelo padrão pois existem tantas variáveis que é praticamente impossível definir um plano de projetos que atenda todo mundo. Vai depende muito mais do cenário e projeto. Mas aqui vão algumas dicas que lhe ajudarão a ficar aderente ao CMMI, MPS.Br e PMI, mas tenha em mente que este não deve ser seu principal objetivo (ficar aderente) e sim, fazer um bom planejamento para seu projeto.

Um bom plano de projeto deve…

… ter seus objetivos definidos
Infelizmente muitos gerentes de projetos falham neste ponto, mas voce deve ter muito claro quais são os objetivos do projeto, tanto para seu cliente quando para você. Para seu cliente a data de entrada do sistema pode ser o principal objetivo do projeto, já você, pode definir entregar com uma semana de antecedência (para reduzir os riscos), reduzir o custo em 10% e por ai vai. O fato é que todos os objetivos devem ser documentados. Outro fator importante é coletar as expectativas de todas as partes interessadas e se necessário,

… ter o escopo definido
Em linhas gerais, o escopo nada mais é do que será feito, então, seu plano de projeto dever detalhado o que será feito em seu projeto. Todas as tarefas e produtos de trabalho fazem parte da definição do escopo. Neste momento você deve definir a WBS do projeto.

… ter estimativas
Você deve ter estimativas de tudo. Estimativas de tamanho, tempo, custos, prazo, recursos, enfim, estimativas que lhe ajudem a fazer o projeto. Como exemplo, o esforço foi estimado com base em uma técnica de dimensionamento como APF ou UCP (ou alguma outra), com este esforço você calculou prazo e consequentemente custo, logo, seu projeto deve seguir estas estimativas, pois caso contrário, o mesmo afundará. Documente sempre qual foi o modelo utilizado para estimativas. Veja mais sobre tamanho em Tamanho importa?

… ter a definição do ciclo de vida do projeto
O ciclo de vida do seu projeto define as fases e atividades padrão de um projeto. Um projeto normalmente tem fases como “Gerenciamento”, “Especificação funcional”, “User Interface”, “Especificação técnica”, “Desenvolvimento”, “Testes”, “Homologação” e “Implantação”. Mas, isto dependerá de projeto a projeto.

… ter um cronograma
Não há muito segredo no desenvolvimento de um cronograma. Ele deve basicamente ter suas fases e atividades, datas, recursos envolvidos, responsáveis, dependências, milestones, esforço, custo, e percentual de completude. Isto é o básico, praticamente todo cronograma tem estes elementos, mas a complexidade do seu cronograma dependerá mais da sua necessidade (seu projeto) do que de um template padrão. Procure sempre manter seu cronograma atualizado e sempre usa-lo em seus eventos de acompanhamento.

Veja o post completo →

Se você esta lendo este artigo provavelmente você é um gerente de projetos ou esta interessado em se tornar um. Então aqui esta uma lista atualizada com várias dicas “must have” que vão ajudar desde aqueles que pretendem se tornar um gerente de projetos até os mais experiêntes GPs. Você deve consulta-la sempre, ela servirá como um guia de referência rápida e será muito útil no seu dia-a-dia. Com ela você poderá lembrar de aspectos importantes que um GP deve conhecer e fazer.

Lista de 20 coisas que todo gerente de projetos deveria saber … e fazer

1- Saiba com se comunicar com todos os níveis dentro da organização

A habilidade de se comunicar com facilidade com pessoas de todos os níveis da organização sobre seu projeto e quase sempre apontado como uma das mais importantes habilidades por GPs. No entando, é importante adaptar a sua mensagem a cada público para assegurar o nível adequado de comunicação. Cada pessoa deverá ser abordado de forma diferente. Alguns precisarão de mais detalhes enquanto outros se contentarão com um simples overview. Se alguém quiser conversar sobre a formatura da oitava série de sua filha, preste atenção à conversa. Você pode até anotar e perguntar mas tarde sobre como foi a festa. Coisas simples como esta causam impacto.

2- Aprenda a falar em público

Um gerente de projetos pode ser muito bom em planejamento e gerenciamento do projeto, mas pode falhar na apresentação de informações aos interessados em um formato fácil e compreensível. Um gerente de projetos deve ter facilidade na passagem de informação de uma forma simples para que qualquer um compreenda. Em uma apresentação sobre o projeto o gerente de projetos deve-se mostrar seguro.

Isto parece ser fácil, mas bons “apresentadores” tipicamente não nascem assim. Você precisará investir em treinamentos de falar em público, treinamentos de apresentação e praticar… praticar muito e obter feedback de suas apresentações.
Obviamente existem pessoas com mais facilidade em uma ou outra coisa, todavia há uma verdade que todos bons apresentadores tem centenas de horas de apresentação.

3- Use templates para lhe ajudar a completar a documentação e manter a coerência, mas lembre-se, os templates são guias e não um guia de regras

É muito bom usar templates porque você não perde tempo reinventando a roda outra vez. Mas não deixe que eles prejudiquem sua criatividade. Trate-os como um roteiro e não tenha medo de tentar algo novo. Quem sabe, você pode descobrir uma maneira melhor de se fazer algo e melhorar o desempenho do projeto.

4- Saiba usar o Earned Value Management System (ou simplesmente EVM)

Inevitavelmente o sponsor do projeto vai perguntar: “Como está o projeto? Está dentro do prazo? Está dentro do orçamento?”.
Você pode ter uma idéia geral, mas como você pode ser mais preciso? Se você estiver utilizando EVM, você poderá divulgar o status do projeto com mais confiança e, consequentemente, ganhar mais credibilidade entre os membros de sua equipe e envolvidos no projeto. Mas, lembre-se, se você não compreender totalmente as métricas ou tampouco verificar a acuracidade dos dados para transmitir a informação de forma eficaz.

5- Obtenha os recursos certos (e mantenha-os com você).

Alguns tem talento nato para isto, outros devem trabalhar melhor esta habilidade, mas esta habilidade trata de conhecer pessoas, nichos e sua rede de relacionamentos em busca de conhecimentos e experiências. Esta tarefa da muito trabalho e leva um bom tempo para montar sua “rede”. Ela também envolve conversar diariamente sobre o trabalho e demais assuntos. A confiança é o alicerce para qualquer relacionamento e com ela as pessoas vão querer colaborar com você para entregar o projeto melhor, dentro do custo e prazo.

6- Gerêncie os stakeholders

É imperativo se comunicar com os stakeholders no início… e depois muitas vezes. Isto não só aumenta a confiança, mas lhe ajuda a obter informações valiosas para que você possa aumentar a probabilidade de sucesso no projeto, entretanto, lembre-se da flexibilidade em seus métodos de comunicação. Algumas pessoas se sentem mais a vontade pessoalmente, outras por email, outras telefone e outras em grupo. Você precisará descobrir como as pessoas se sentem mais confortáveis pois assim eles ficarão mais dispostos a cooperar com o projeto.

7- Saiba como resolver problemas

Um problema pode ser a diferença entre seu estado atual e sua meta, mas também pode ser uma oportunidade de melhoria.Tenha (e passe) segurança em buscar soluções. Note que os problemas não chegam como resultado de fatores externos ou eventos ruins. Qualquer nova possibilidade de melhoria traz junto “um problema” que precisa ser revolvido.

8- Aprenda as habilidades (críticas) necessárias para se fazer o trabalho bem feito.

Ter foco técnico não é o suficiente para ser um gerente de projetos bem sucedido (na verdade isto é o que menos importa); Você também precisará de habilidades críticas como comunicação (escrita e verbal), negociação e tomada de decisões para ajudar a fazer seu trabalho com mais eficiência. Habilidades como estas são fundamentais, quando você cruza a fronteira organizacional para obter ajuda ou obter informações, mas estas habilidades precisam ser desenvolvidas, elas não vem naturalmente.

Você deve se manter informado através de livros, cursos, webminars, podcasts e utilizar a web a procura de sites, blogs, artigos e whitepapers. Implemente algo novo a cada dia e incorpore as coisas boas no trabalho do seu dia-a-dia. Antes mesmo que você perceba, você implementará um processo de melhoria contínua e estas habilidades e conhecimentos que você não tinha, serão incorporados naturalmente e você estará a procura de outros.
Veja o post completo →

Atendendo a pedidos, segue a descrição rápida das áreas de conhecimento do PMI.

As áreas de conhecimento do PMI da Gerência de Projetos descrevem os conhecimentos em determinadas áreas que um gerente de projetos deve ter (e praticar). Assim com CMMI e MPS.Br, as “instruções” foram baseadas em boas práticas de mercado coletadas ao longo dos anos e que quando praticadas reduzem o risco de fracasso dos projetos.
O PMI organizou estes processo em nove áreas de processo conforme descrito abaixo:

Gerência da Integração do Projeto

Descreve os processos necessários para que diversos elementos de um projeto sejam coordenados de forma eficiente. Entre os produtos estão o desenvolvimento do plano do projeto, execução do plano do projeto e controle geral de mudanças.

Gerência do Escopo do Projeto

Define os processos necessários para assegurar que o projeto contemple todo o trabalho necessário, e nada mais que isso, para finalizar o projeto com sucesso. É composta por iniciação, planejamento do escopo, detalhamento do escopo, verificação do escopo e controle de mudanças do escopo. Veja também o artigo: Entendendo o gerenciamento de mudanças

Gerência do Tempo do Projeto

Trata dos processos necessários para assegurar que o projeto termine dentro do prazo planejado. É composta por definição das atividades, dando seqüência às atividades, estimativa da duração das atividades, desenvolvimento do cronograma e controle do cronograma.

Gerência do Custo do Projeto

Relata os processos necessários para assegurar que o projeto seja completado dentro do orçamento previsto. É composta por planejamento dos recursos, estimativa dos custos, orçamento dos custos e controle dos custos.

Gerência da Qualidade do Projeto

Descreve os processos necessários para assegurar que as necessidades que originaram o desenvolvimento do projeto serão satisfeitas. É composta por planejamento da qualidade, garantia da qualidade e controle da qualidade. Veja também: Qualidade custa mais caro?
Veja o post completo →

Todos que se interessaram por Gerenciamento de Projetos já ouviram que mais de 80% do tempo de um GP é gasto com comunicação.

O PMBOK afirma que: “A comunicação foi identificada como a maior razão de sucessoou fracasso de um projeto”.

Apesar disto, dentro da gigantesca bibliografia de gerenciamento de projeto é extremamente difícil encontrar bons livros falando sobre o assunto, mesmo o PMBOK, depois de afirmar a sua importância através da frase citada acima, dedica apenas 21 de suas 336 páginas ao Gerenciamento da Comunicação,  e vale ressaltar que isso significa um avanço em relação a versão 2003, que dedicava apenas 14 páginas.

O Grande problema que percebi em várias metodologias de desenvolvimento/gerenciamento com que trabalhei é que se confunde comunicação com documentação.

Documentação é importante sim, para que todos saibam o que está acontecendo, para nivelar informações e para sinalizar o acompanhamento do projeto.

…o que não está documentado, não foi combinado ou não foi dito…

Dentro da área de conhecimento de Gerenciamento da Comunicação, o PMBOK define 5 Processos:

1. Identificar Partes Interessadas
2. Planejar as Comunicações
3. Reportar o Desempenho
4. Gerenciar as Expectativas das Partes Interessadas
5. Distribuir Informações

Em minha experiência de projetos, gerenciando e sendo gerenciado, pude perceber que os processos que recebem maior atenção são “Reportar o Desempenho” e “Distribuir Informações”, muito provavelmente porque esses elementos são, basicamente, processos de documentação.

Ouvi certa vez de um superintendente, em reunião para Gerentes de Projeto, a seguinte frase: “…se falharmos na documentação do que ocorreu durante o projeto, ficamos sem defesa, nas mãos do cliente…”

Realmente isso é verdade, se não está documentado, não temos defesa, MAS…Precisamos mesmo nos defender sempre?

Para mim essa metodologia devia se chamar COASS (Cover Our ASS!)

Veja o post completo →

Esta área de processo é muito mal compreendida em TI (e mal utilizada). A maioria das empresas define como risco um percentual a mais para se inflar o custo de um projeto como por exemplo:

• Cliente novo: 10%
• Falta de pessoal disponível: 5%
• Linguagem nova: 5%
• Ambiente “encardido”: 10%

E por ai vai… Com isso, se o projeto inicialmente custava R$ 50.000,00, agora ele custará 30% a mais, ou seja, R$ 65.000,00.

Esta é uma análise equivocada do que é riscos em projeto, e consequentemente não tratou o problema (risco), apenas criou um fundo para tentar cobrir um possível prejuizo.

Esta análise equivocada é mais comum do que parece, constantemente vejo casos assim em empresas que presto consultoria, mas isso acontece porque muitos acham que gerenciamento de riscos é um bixo de sete cabeças, já vi muita gente falar “isso não serve pra nada” e até mesmo “Isso é teoria, na vida real ninguém usa”.

Então, vamos “descomplicar” este assunto. Primeiramente, Gerenciamento de riscos é mais fácil do que parece e é muito provável que você faça isso no seu dia-a-dia de forma tão natural que nem perceba. Vamos a um exemplo:

Você vai em uma concessionária VW e compra um Fox zerinho. A entrada veio de suas economias de dois anos e o restante foi financiado em 48 vezes.

Agora… onde estão os riscos com esta nova aquisição? Vejamos alguns:

• Seu Fox pode ser roubado
• Alguém pode bater nele
• Você pode sofrer um acidente
• Você pode tomar uma multa
• E várias outras coisas

Estes são alguns dos riscos e obviamente você precisa tratá-los e há várias formas para isso como contingência, mitigação, transferência e outros.

Vamos tratar este caso juntos. Se o seu Fox for roubado, além de ficar sem carro você ainda terá que pagar as prestações, então, para isso você precisa de uma contingência, ou seja, um Plano B. Você contrata um seguro para seu carro. Com isso você transferiu o risco para seguradora, e esta por sua vez, coloca várias cláusulas no contrato para você não abusar ou agir de má fé.

Veja o post completo →

1. Lista de empresas CMMI no brasil
   A lista mais completa  e atualizada de avaliações CMMI das empresas brasileiras
   .
2. Lista de empresas MPS.BR no Brasil
   Lista super completa de todas as empresas MPS.Br do Brasil
   .
3. 49 provérbios do gerenciamento de projetos
   Não deixe de ler! Muito legal
   .
4. O que é CMMI?
   Uma visão geral do que é o CMMI para iniciantes. Veja também a versão melhorada O que é CMMI II
   .
5. Tutorial mini projeto utilizando Análise de pontos por função
   Tutorial dividido em 3 partes, veja a Parte 1, Parte 2 e Parte 3
   .
6. 101 dicas para implementação do CMMI nível 2
   São 101 dicas que vão te ajudar na implementação do CMMI nível 2 e MPS.Br F e G. Veja também a Segunda Parte
   .
7. Top 10 dicas para administração de tempo
   Dez excelente dicas para administrar e otimizar o tempo
   .
8. Plano de gerenciamento de projeto
   Muito se fala do plano de projeto, este plano é bem difundido pelo PMI, CMMI e MPS.Br. Mas… existe também o plano de gerenciamento do projeto, que é um documento que ajudará o gerente a tomar decisões mais rapidamente. Vale a pena a leitura.
   .
9. Como anda o CMMI no mundo?
   Uma visão gerão sobre a adoção do modelo CMMI no mundo com informações como “quantas empresas foram avaliadas no CMMI”, “Quantas avaliações tem um país (e quais)”, “Quantas empresas CMMI 5 existem no mundo” e muito mais.
   .
10. Uma visão geral sobre qualidade de software
    Um artigo muito bom sobre qualidade de software e como ela pode ajudar a sua empresa
    .
11. OBA! Quero ser gerente de projetos!
    Um relato sobre o que leva as pessoas a desejarem tanto ser “gerente de projetos”
    .
12. Como avaliar se meus fornecedores seguem CMMI/MPS.Br?
    Uma excelente lista de 10 dicas de como avaliar se o seu fornecedor segue ou não CMMI ou MPS.Br
    .
13. 20 pontos para qualidade e melhoria de processos
    20 excelentes dicas sobre qualidade e melhoria de processos de software com CMMI e MPS.Br
    .
14. Aderência do CMMI com métodos ágeis (SCRUM, XP e FDD)
    Artigo interessante com um mapa que mostra a aderência do Agile com CMMI, e, apesar de muitos acharem que ambos são opostos, eles não são.
    .
15. Gerente de projetos. Uma carreira acidental?
    Outro relato sobre o que é a carreira de gerentes de projeto e o que é necessário para se tornar um gerente de projetos ou se especializar nesta carreira

Veja o post completo →

O tamanho do seu projeto, o tamanho da sua equipe, o tamanho de suas entregas, o tamanho de seus checklist, o tamanho dos seus códigos – enfim, tudo em um projeto depende do TAMANHO. O tamanho muda as regras de como o jogo será jogado.

Quanto maior o projeto (em tamanho ou complexidade) mais importante é para o gerente de projetos, “quebra-lo” em módulos ou projetos menores e dividir a responsabilidade com pessoal qualificado.

Isto garantirá que todos os membros do projeto (incluindo o gerente do projeto), poderão ver o quadro geral sem se perder em detalhes enquanto estão verificando a saúde (status) do projeto.

Projetos distribuidos tendem a ser maiores que muitos outros tipos de projeto. O gerente deve usar varias táticas para não deixar que o tamanho influencie nas partes menores. A palavra “grande” quer dizer muitas coisas, mas nenhuma em específico. Ela pode querer dizer que você tem uma equipe de 10 pessoas trabalhando durante 12 meses, como também pode querer dizer que você tem uma equipe de centenas de pessoas trabalhando em manutenção de sistemas (como por exemplo um outsourcing).

Aqui vão algumas dicas de como trabalhar com o “tamanho correto” e garantir que todos entenderam como as peças menores influenciam no todo.

• Quebre o projeto em projetos menores, fluxos de trabalho menores, módulos menores ou pacotes menores no melhor jeito possível para seu gerenciamento.
• Garanta que cada fluxo de trabalho tenha pelo menos um ponto focal responsável por sua entrega
  Se possivel, tente colocar alguns membros da equipe com dois chapéus em fluxos de trabalho distintos. Isto melhorará no entendimento da visão do todo (o projeto).
• Acompanhe o desempenho (Não importa o jeito, mas acompanhe) de cada fluxo de trabalho ou pacote SEPARADAMENTE e colete alguns indicadores periodicamente para montar o todo.
• Documente e compartilhe os riscos, casos, pressuposto e dependências de cada pacote.

Veja o post completo →