Documentação do projeto

Publicado por John Grass, PMP em 25 Jan 2010 | sob: Planejamento, Comunicação, Documentação

Quanto maior o projeto, mais difícil será para compartilhar, sem transtorno, as informações entre todos os membros da equipe e as parte interessadas. Isso aplica-se especialmente nos casos em que mais de uma pessoa trabalha na mesma entrega. Se o gerente do projeto não pensar com antecedência nos processos de gerenciamento de documentos, a equipe do projeto terá muita dificuldade para encontrar informações relevantes e em conseqüência disso ficará frustrada ao ter que lidar com formatos inconsistentes. Isso geralmente resulta em confusão e esforço extra para refazer o trabalho que já está “concluído”.

Em geral, essa idéia do gerenciamento de documentos é semelhante ao que é feito no gerenciamento de código fonte de computador. O gerenciamento do código fonte deve ser feito sob a direção de uma ferramenta de gerenciamento de mudança de software, ou de um banco de dados que acompanhe a propriedade e a versão. Sem essas ferramentas, seria impossível desenvolver e dar suporte a grandes projetos de software. Da mesma forma, os documentos devem ser gerenciados e controlados – especialmente em projetos grandes.

Alguns exemplos ajudarão a explicar esse conceito. Digamos que o seu projeto irá criar muitos documentos que precisam ser armazenados e compartilhados – por exemplo, os documentos do “Termo de Abertura do projeto”, o “Registro de Incidências Problemáticas”, os “Requisitos do Negocio”, o “Plano de Testes”, etc. Depois que os documentos forem criados, os membros da equipe necessitarão saber aonde os mesmos serão armazenados. Dependendo do seu software e da sofisticação da sua organização em relação ao armazenamento, os documentos poderão ser armazenados dentro de um arquivo de Rede, em um arquivo dentro do disco rígido do seu computador, em um pacote de software para gerenciamento de documentos, etc. Também, após o documento ter sido criado, você necessitará saber quem terá acesso a esses documentos. Por exemplo, todos os membros da equipe poderão acessar os documentos, mas somente para leitura e não para mudanças. Alem disso, você deverá criar um nome padronizado para os documentos iniciais e para todas as revisões dos mesmos. Por exemplo, se você atualizar o documento “Termo de Abertura do projeto”, que processo você deverá seguir? Você acha que será necessário substituir a versão antiga? ou, salvar o documento original e chamar este novo documento de “Termo de Abertura do projeto - Versão 2″. Tudo isso faz parte dos procedimentos de gerenciamento de documentos.

Vamos ver também os relatórios de andamento (Status). Você deverá determinar com antecedência os nomes padrões para os relatórios de andamento (Status). Se cada membro da equipe emitir um relatório de andamento (Status) ao gerente do projeto, logo o gerente do projeto terá dúzias ou centenas de relatórios de andamento (Status). Se o formato do documento for, “Data / Nome / Relatório de Andamento (Status)”, os relatórios serão organizados na ordem cronológica. Se o formato do documento for, “Nome / Relatório de Andamento (Status) / Data”, os relatórios serão organizados pelo nome da pessoa. Talvez o ideal seria que o gerente do projeto descartasse os relatórios de andamento (Status) após a revisão. Todas estas questões são componentes do gerenciamento de documentos.

Essas considerações são triviais para projetos pequenos. Para projetos grandes, esse processo precisa ser planejado com antecedência, caso contrário, poderá haver muita confusão, incerteza e trabalho extra quando o projeto estiver em andamento.

Dados Estruturados e Dados Não Estruturados

Os dados podem ser armazenados em dois estados - estruturados e não estruturados. Os dados estruturados referem-se à informação que é armazenada no formato repetitivo e estruturado. Também referem-se às pastas, às tabelas, às bases de dados, aos armazéns de dados, etc. Este tipo de dados é facilmente armazenado e acessado por um programa de computador.

Por outro lado, os dados não estruturados estarão tipicamente em um formato que seja mais fácil para o ser humano compreender. Os dados não estruturados incluem documentos, imagens, gráficos, vídeos, áudios, etc. Os dados não estruturados podem ser cada vez mais manipulados através de um computador, mas a compreensão básica do conteúdo ainda é melhor que seja executada por humanos.
Embora os documentos criados por um projeto sejam de interesse e preocupação dos membros das equipes dos projetos, o conceito do termo “Gerenciamento de Documentos” poderá ser estendido para incluir quaisquer tipos de dados não estruturados como descrito acima. Ou seja, se o seu projeto gerar pastas de áudios e vídeos, você poderá usar as mesmas técnicas de padrões de nomes que são utilizadas para os documentos do projeto, indexação, armazenamento no repositório, etc.

Dados Estruturados

- Campos, registros, arquivos, tabelas
- Códigos, modelos, scripts
- Ferramentas de Códigos Fonte, bancos de dados
- Difícil para organizar sem ferramentas ou estrutura

Dados Não Estruturados

- Documentos, fotos, gráficos, textos, vídeos, chat
- Ferramentas de documentos, difícil para adquirir
- Pode ser organizado sem ferramenta

Para maiores detalhes sobre Gerenciamento de Documentos, veja  >> Gerenciando a Comunicação

Gerenciar pró-ativamente os recursos humanos em uma organização matricial

Publicado por John Grass, PMP em 18 Jan 2010 | sob: Planejamento, Comunicação, RH

Uma das partes frustrantes em ser um gerente de projetos é que pode ser difícil de gerenciar um projeto quando ele não tem nenhuma autoridade formal sobre os membros de sua equipe. De uma perspectiva organizacional, se as pessoas não relatam diretamente ao gerente do projeto como um gerente funcional, então provavelmente essas pessoas estão trabalhando em algum tipo de estrutura matricial. Uma das vantagens principais de uma organização matricial é que ela utiliza os recursos humanos com maior eficiência, mas também pode ser muito desafiadora para os gerentes de projetos.

Como você manterá os membros da equipe responsáveis pelos seus prazos finais sem ter esta autoridade?

Da parte das pessoas, embora os membros da equipe não relatam diretamente ao gerente do projeto, o desempenho sobre seus trabalhos no projeto deve ser incluído nas revisões de desempenho anuais dos mesmos. O Gerente do projeto deverá comunicar aos membros da equipe que seus desempenhos sobre o projeto serão incluídos em suas revisões de desempenho anual. Também, isso deverá ser reiterado e concordado pelos gerentes diretos dos recursos humanos envolvidos.

Naturalmente, se os membros da equipe estiverem faltando com seus compromissos em termos de prazos, você deverá tentar determinar a causa. Por exemplo, se for devido a falta de habilidades, isto deverá ser resolvido através de treinamento ou da realocação de recursos. Se o problema for pela falta de compreensão das expectativas esperadas, então você poderá ter que fazer algumas mudanças em termos de comunicação.

Pela parte do gerenciamento dos processos, há as técnicas e os processos de gerenciamento de projetos que devem ser utilizados. Primeiramente, se a disponibilidade e o desempenho da equipe estiver na dúvida, você deverá levantar cedo este problema no projeto como um risco. Como parte de gerenciamento dos riscos, você necessitará criar um plano pró-ativo para gerenciar e mitigar o impacto no projeto. Quando as pessoas faltarem com seus compromissos em relação aos prazos e o prazo final do projeto estiver em risco, você poderá necessitar informar este problema a gerência e executar o processo de gerenciamento das incidências problemáticas. Durante o gerenciamento das incidências problemáticas, você deverá procurar a causa do problema e tentar resolvê-lo.

Além disso, certifique-se de que os membros da sua equipe estão comunicando-se pró-ativamente com você. Em muitos casos, não é o fato de as pessoas faltarem com seus compromissos em termos de prazos que lhe frustra, mas sim porque o membro da equipe não se comunica pro-ativamente. Se o membro da equipe, comunicar-se pró-ativamente, você poderá ter tempo para avaliar a situação, o impacto, resolver os problemas ou no mínimo comunicar pró-ativamente o problema e a solução as partes interessadas apropriadas. O gerente do projeto também necessita comunicar-se pró-ativamente. Comunique-se bem com a sua equipe e certifique-se de que a mesma compreende as datas e as suas expectativas. Também, comunique-se pró-ativamente com os gerentes diretos dos membros da equipe e certifique-se de que os mesmos saibam quando houver problemas sobre o compartilhamento dos recursos e com o desempenho.

O gerenciamento em uma organização matricial envolve um balanço complexo e delicado entre os gerentes de projetos e os gerentes diretos dos recursos humanos. Nestas situações, geralmente o gerente de projeto tem autoridade limitada no gerenciamento dos recursos humanos. Mesmo assim, é possível concluir com sucesso seus projetos. Existe muitos processos e técnicas de gerenciamento de projetos que poderão ajudá-lo. Utilize-as para levantar riscos e problemas quando forem necessários. Também, certifique-se de utilizar o patrocinador do projeto. O patrocinador poderá ajudá-lo a gerar urgência e foco, e também poderá forçar um impacto nos gerentes diretos dos recursos humanos para certificar-se de que você terá os recursos necessários para ser bem-sucedido.

Para maiores detalhes sobre Gerenciamento de Recursos Humanos, veja  >> Gerenciando os Recursos Humanos

Validar as estimativas com os membros da equipe do projeto

Publicado por John Grass, PMP em 10 Jan 2010 | sob: Gerenciando o Projeto, Comunicação, Estimativas, Custos

Uma das responsabilidades preliminares de um gerente de projetos é construir o cronograma do projeto, atribuir as atividades do cronograma aos membros da equipe e informá-los que os mesmos são responsáveis pelas atividades e pela entrega das mesmas dentro das expectativas.

Delegar a responsabilidade aos membros da equipe para entregar as atividades dentro das expectativas é correto, mas você acha isso justo? Vamos supor que você é um gerente de projetos e foi atribuído a um projeto depois que as estimativas para o cronograma e orçamento foram estabelecidos. Você poderá achar isso injusto, porque você não foi envolvido no processo de criação das estimativas. Também, você poderá achar que, se você será o responsável pelo cronograma e pelo orçamento do projeto, você precisa ser envolvido na criação dos mesmos.

Agora que você entende o problema sobre a atribuição das atividades aos membros da equipe. Então, você acha justo atribuir a responsabilidade da execução das atividades aos membros da equipe sem que eles tenham participado do processo de estimação? A resposta é a mesma “Não”.

Há duas maneiras para evitar este problema e certificar-se de que os membros da equipe aceitarão as estimativas. A primeira é tentar envolver antecipadamente os membros da equipe no processo de estimação. Isso nem sempre é prático, mas às vezes é possível. (De fato, você poderá precisar da ajuda dos membros da equipe do projeto para criar realmente o cronograma e o orçamento do projeto.) Se os membros da equipe forem envolvidos no processo de estimação, os mesmos poderão se responsabilizar pela entrega das atividades dentro destas estimativas. (Se os membros da equipe não aceitarem a responsabilidade dentro das estimativas que eles mesmos ajudaram a criar, então você deverá perguntar-se, se as estimativas realmente são válidas.)

Por outro lado, em muitos projetos os membros da equipe do projeto não são atribuídos até que o cronograma e o orçamento do projeto estejam estabelecidos. As pessoas que criam as estimativas iniciais, fazem algumas suposições sobre o desempenho “médio” dos membros da equipe que serão atribuídos e criam as estimativas baseadas nessas suposições.

Neste caso é apropriado atribuir uma atividade a um membro da equipe e solicitar que o mesmo valide as estimativas, se as mesmas aparentam ser razoáveis ou não. Você não está procurando uma estimativa com um fator de 100% de confiança. Você está apenas tentando validar se a estimativa sobre o esforço, o prazo e o orçamento aparentam ser razoáveis. Se o membro da equipe concordar com as estimativas, então você poderá manter o mesmo como responsável pela entrega da atividade dentro dessas estimativas.

Naturalmente, quando você atribuir primeiramente as atividades aos membros da equipe, os mesmos poderão não saber o suficiente para responder se a estimativa é razoável ou não. Ele poderá necessitar de algum tempo e talvez ter que começar a trabalhar realmente na atividade para poder responder. Isso não é um problema. Neste caso, você atribui a atividade junto com o esforço, o orçamento e o prazo final estimado. Então você solicita que o membro da equipe valide o MAIS CEDO POSSÍVEL se o trabalho poderá ser realizado dentro destas estimativas. Se o membro da equipe sentir que as estimativas são imprecisas, o mesmo deverá fornecer uma estimativa mais realística. Como gerente do projeto, você deverá negociar com o membro da equipe para obter um acordo. Entretanto, quando você e o membro da equipe chegarem a um acordo, você poderá manter o mesmo como responsável pela entrega da atividade dentro das estimativas acordadas.

A chave deste cenário é que o membro da equipe deverá notificar o gerente do projeto o MAIS CEDO POSSÍVEL, que a data final prévia é inaceitável. É irrelevante que o membro da equipe espere faltar o prazo final, para então informar que as estimativas estão incorretas.

Estas duas abordagens são maneiras de manter os membros da equipe responsáveis por suas atividades, e da mesma forma ser justo, permitindo a eles discutirem sobre as estimativas e chegarem a um acordo. Uma vez que chegarem a um acordo, você poderá manter o mesmo como responsável pela entrega da atividade dentro das estimativas acordadas.

Para maiores detalhes sobre Gerenciamento de Cronograma e Orçamento, veja  >> Gerenciando o Cronograma e o Orçamento

- Próxima Página »