O que significa realmente controlo de projeto

O termo controlo tem vários significados. Aqueles que são novos na gestão de projeto ficam inicialmente desanimados usando o termo “controlo”, porque equivocadamente o equacionam com o conceito de autoridade.

No mundo da gestão de projetos, o controlo tem muito pouco a ver com dizer às pessoas o que fazer, ditando as ações ou pensamentos, ou tentando forçá-las a comportar-se de certa forma - todas as quais são interpretações comuns de controlo.

Na gestão de projetos, o termo “controlo” é muito mais análogo a dirigir um navio. Trata-se de fazer continuamente ajustes no curso com um objetivo principal em mente: trazer o navio para um porto seguro, como prometido no início da viagem. E a viagem do projeto bem-sucedida inclui a identificação de um destino específico, o mapeamento cuidadoso de uma rota para chegar lá, a avaliação da localização durante a viagem e a observação atenta do que está por vir.

Objetivo do Controlo do Projeto

Os gestores de projeto novatos (e alguns experientes!) costumam cometer o mesmo erro ao tentar manter o controlo dos projetos. Eles envolvem-se no aqui e agora - na medição e avaliação da situação imediata - com a exclusão de todo o resto. Eles calculam a posição atual e o quanto estão fora do curso. Isso é o que eles reportam ao gestor e prometem corrigir. Todo o foco deles consiste em permanecer na linha que eles traçaram do começo ao fim do projeto. Infelizmente, controlar o destino do projeto não é tão simples.

Como veremos, avaliar onde estamos em termos de onde deveríamos estar certamente faz parte do controlo geral e "voltar à rota" é quase sempre uma boa estratégia. Mas a missão principal é entregar o que prometeu, por isso deve pensar em "manter o controlo" em termos de minimizar a distância entre o local onde acaba e o aquele em que disse que acabaria.

Significa que o controlo geral do projeto exige um olho no futuro, como mostra a fórmula:

Variação atual calculada + variação futura estimada = variação final do projeto

Manter o adequado controlo requer que considere três parâmetros: (a) onde está, comparado com o local em que deveria estar; (b) o que há pela frente que possa afetá-lo; e (c) onde vai acabar, comparado com o lugar onde disse que acabaria. Tenha em mente que (a) e (b) são usados principalmente como funções de controlo interno (embora você possa optar por reportá-los fora da equipe). São usados para avaliar (c). Correndo o risco de ser repetitivo, o foco principal deve ser sempre avaliar onde acha que vai acabar.

Há duas razões para isso.

Primeiro, deve realizar uma ação corretiva inteligente e significativa com este ponto final em mente. Orientar o navio deve incluir mais do que apenas direcioná-lo de volta ao curso; também deve incluir o reconhecimento de que há um motivo à frente que terá que percorrer ou percorrer o próximo ponto de terra que começou desde que começou sua viagem. O futuro será sempre diferente do esperado no início do projeto. Os pressupostos serão revistos, as condições operacionais serão alteradas e novas coisas serão lançadas no caminho. Às vezes, as ações tomadas agora devem compensar as futuras fontes de variação, bem como as variações criadas pelo desempenho passado.

A segunda razão pela qual precisa concentrar-se no ponto final refere-se aos relatórios de gestão. Na maioria dos casos, o que provavelmente mais interessa à gestão é uma previsão de onde acha que vai acabar: esse é o tipo de informação de que precisam para gerir a empresa. É possível informar a gestão que está duas semanas atrasado ou que o valor de x € acima do orçamento pode ou não ter valor para eles. Relatar que espera que o projeto seja concluído com três semanas de atraso ou xxx € acima do orçamento tem muito mais probabilidade de ter valor.

O que Controla na realidade

Neste ponto, provavelmente vai dizer: "OK, então deveria estar focado no ponto final do projeto e deveria tentar" voltar à rota "e minimizar as variações. Mas o ponto final de quê? Voltar para que faixa de rodagem? E que tipo de variação falamos?” Todas são boas perguntas.

As respostas a estas perguntas conduzirão de volta à discussão sobre as dimensões do sucesso do projeto. A medida mais fundamental do sucesso do projeto refere-se ao cumprimento das metas acordadas em cada uma das dimensões. Estas são as metas que prometeu cumprir no início do projeto; esses são os alvos que você deve focar no controlo.

Dois dos alvos pertencem ao consumo de recursos:

• Cronograma: O projeto foi concluído no prazo? (Quanto tempo demorámos?)

• Custo: O projeto teve um custo? (Quanto gastámos?)

Os outros dois alvos estão ligados às entregas do projeto:

• Funcionalidade: Os entregáveis do projeto têm a capacidade esperada? (O que é que eles podem fazer?)

• Qualidade: Os resultados alcançados são tão bons quanto prometidos? (Qual a dimensão de bem pode ser alcançada?)

No que diz respeito a muitos gestores de organizações, o desfecho ideal ocorre quando um projeto responde a estes quatro objetivos exatamente como prometido. Embora os “alvos que são alcançados” sejam frequentemente caracterizados como desejáveis, atingir alvos fornece um nível de previsibilidade que a maioria dos gestores organizacionais valoriza. Os dois primeiros alvos (tempo e custo) geralmente recebem mais atenção; daí a frase muito comum "controlar no tempo e no orçamento".

Às vezes, no entanto, controlar o custo e o cronograma recebe muita atenção e o desempenho de entrega não é monitorizado tanto quanto deveria. Este é um grande descuido, em que deve concentrar-se em evitar.

Portanto, Controlo de projeto é. Realmente, minimizar a distância entre o prometido e o alcançado.

Elementos do processo de controlo requeridos

Os planos de projeto detalhados são criados para satisfazer dois objetivos básicos: primeiro, fornecer um mapa para a equipe do projeto acompanhar durante a execução do projeto; e, segundo, fornecer um instrumento que possa usar para avaliar se o projeto está ou não no curso. Em termos simples, não poderá manter o controlo sobre o projeto se não tiver um plano com credibilidade e devidamente detalhado.

A capacidade de avaliar o progresso do projeto, calcular a variação do plano e prever o futuro depende de vários elementos-chave do processo. Entre esses elementos estão os seguintes:

• Uma linha de base de medição, a baseline ou plano aprovado
• Processos e métodos para recolha de dados
• A capacidade de obter bons dados
• Enfase no cumprimento dos prazos
• Processos, ferramentas e métodos para analisar o desempenho passado, presente e futuro

Identificar o que pode atingir o projeto

Uma séria abordagem do Risco continua a ser a maior lacuna nos projetos no nosso país.A razão para isso entronca no deficiente conhecimento mas também na dificuldade de enfrentar a incerteza de forma prática.

O primeiro passo no processo de gestão de risco é descobrir o que enfrentamos. Que tipos de coisas ameaçam a capacidade de fornecer o que se prometeu? Tudo começa com a incerteza de não saber exatamente como as coisas vão acabar. Esta é apenas outra maneira de dizer que muitos aspetos dos projetos são imprevisíveis, apesar dos esforços para realizá-los. Eis algumas das áreas mais comuns de incerteza.

Área	Descrição
Âmbito	Extensão estimada do trabalho, capacidade de definir com clareza o trabalho, erros de desenho e omissões, mudança de âmbito dirigida pelo cliente
Tempo	Duração estimada do projeto, duração estimada de atividades, tempo para o mercado, data de lançamento, escala de revisões de gestão e aprovações
Custo	Custos estimados do projeto, custos de produção do procurement, custos de manutenção, Inflação, variações cambiais, limitações de orçamento
Tecnologia	Expetativas do cliente, probabilidade de sucesso, capacidade de escalação, sucesso do design, capacidade de produção
Recursos	Quantidade, qualidade, disponibilidade, competências adequadas, definição de funções e responsabilidades
Organizacional	Prioridades e conhecimentos do cliente, coordenação entre departamentos
Adaptação	Expetativas dos utilizadores, volume de vendas, demografia, qualidade, geografia, economia
Fatores externos	Ações e reações externas, regulação

Tabela 1 - Áreas típicas de alta incerteza

A partir destas fontes de incerteza, surgem questões. Estas são o que precisa descobrir, problemas potenciais específicos, quantos você puder imaginar. Mas como vai identificar problemas? Não há uma fórmula mágica para identificar possíveis ameaças ao seu projeto. Isso exigirá conhecimento específico do projeto, capacidade intelectual significativa e capacidade de especular. Hummm ... isso soa como uma excelente oportunidade para um evento de team-building.

Os melhores eventos de teambuilding são aqueles em que os membros da equipa expandem os conhecimentos uns dos outros e do projeto ao mesmo tempo. Identificar possíveis problemas como equipa é uma maneira ideal de conseguir isso. Caracterizo o efeito de eventos como este como construção da inteligência coletiva da equipa. Especificamente, a abordagem começa pela reunião de toda a equipe. Recomendo reservar de duas a quatro horas, dependendo do tamanho e da complexidade do projeto. Reúna cada peça Reúna toda a documentação que você puder e peça aos outros que façam o mesmo.

Documentos em background típicos podem incluir o Documento de Requisitos, o Documento de Definição do Projeto e o business case. De valor mais imediato, serão os documentos de planeamento do projeto, como a WBS, o cronograma de controle do projeto e a Matriz de Atribuição de Responsabilidades. Finalmente, estruture qualquer documentação de suporte relevante, como base de planos de estimativas, suposições de planeamento e o diagrama de rede usado para o desenvolvimento do cronograma.

O ponto central de tudo isso é que pretendemos que o maior número possível de documentos ajude e estimule o pensamento sobre possíveis problemas. Uma lista de verificação também pode ser bastante útil para estimular a especulação. Considere usar uma lista de verificação similar a esta quando realizar a reunião com a equipa.

Âmbito do Projeto _ Cliente adiciona âmbito ou funcionalidades _ Trabalho não pode ser definido com rigor _ Âmbito está subestimado _ Objetivos do projeto mudam	Instalações e equipamento _Indisponibilidade _Fraca confiança _Incompatibilidade com existente _Limitações proprietárias _Fraca flexibilidade _Má localização e espaço	Pessoal _Férias/Doenças _Família e outros _Interesses em conflito _Distrações externas _Questões éticas _Questões morais
Cronograma do Projeto _ duração subestimada do projeto _ Data de fim altera-se durante o projeto _ Data de fim irrealista _ Atraso nas aprovações _ Revisões da gestão atrasam projeto	Recursos _Mudança nos elementos da equipa _Financiamento _Custos/despesas incertos _Indisponibilidades _Prioridades desalinhadas	Interpessoais _Performance/ produtividade _Conflitos interpessoais _ Desenvolvimento _Má motivação e atitudes _Competências desajustadas
Materiais _ Fonte e disponibilidade _ Integração pobre com o existente _Deficiente confiança do fornecedor _ Confiabilidade do material _Qualidade fora do standard _Alto preço	Organizacional _Difusas funções e responsabilidades _Pobre delegação _Relações más entre unidades _Falta de coordenação _Conflitos entre unidades _Pobres comunicações _Limitações de política	Influências Externas _Meteorologia e desastres _Regulação e governo _Higiene e Segurança _Barreiras culturais _Tensões políticas _Mudanças económicas _Posição política desfavorável

Tabela 2 - Lista de verificação de questões

Relacione o máximo de problemas possíveis, com o uso técnicas de brainstorming. Embora não queira sufocar a criatividade, tente manter a lista com um tamanho razoável (talvez de 30 a 50, dependendo do tamanho e da complexidade do projeto).

Ao listar possíveis problemas que ameaçam o projeto, não perca de vista o conceito de incerteza. Lembre-se de que a falta de informação, conhecimento e compreensão é realmente o inimigo. Em outras palavras, pense nas maiores “ameaças” como aquelas que têm o maior potencial para o desviar o mais longe possível - numa direção desfavorável.

Como sabemos que os requisitos da solução estão concluídos?

Até onde é que podemos levar a Elicitação (escolha de requisitos) num projecto? Parece-me que, de forma definitiva, ninguém sabe a resposta. Será muito dispendioso capturar todos os requisitos, assunções, regras, relações e ligações escondidas associados à solução em construção. Então temos de ter uma forma de saber quando fizemos o que deve ser feito.

Conforme se elícita, analisa e documenta requisitos, devemos estar atentos à informação que a reunir e determinar o tempo que passa entre a descoberta de novos requisitos ou mudanças significativas aos requisitos existentes. Quando a duração excede um determinado limiar, então termine as actividades de recolha de requisitos – este é o processo de preparação de pipocas no microondas, ou a Via das Pipocas.


Este limiar pode, ainda, ser identificado com base num princípio de confirmação: Se, durante o processo de descoberta de requisitos se chega a um momento em que se continua a acumular informação mas esta não se traduz em novos ou alterados requisitos, então sabemos que devemos ter chegado ao fim.

Esta métrica é a solução melhor para situações em que no analista de negócio tem como propósito elicitar e documentar os requisitos de negócio detalhados quando o projecto possui “um charter definido com razoabilidade e objectivos de negócios claros”. Mas, é ainda útil, durante todo o ciclo de vida do projecto, quando se tenta definir âmbito e estabelecer requisitos de negócio para o projecto.

O desenvolvimento de requisitos é um processo iterativo, que se inicia a um alto nível de compreensão das capacidades requeridas, estas são então decompostas em componentes mais pequenos, que são por sua vez mais fáceis de tratar e desta forma determinar até que ponto estamos «terminados» em cada uma delas. Alguns exemplos do que pode ser tratado como componente independente, incluem:

• Definição do Âmbito – quais as capacidades que serão e que não serão incluídas no âmbito do projecto.
• Regras de Negócio – Regras referente à tomada de decisões operacionais que devem ser tomadas em atenção na solução.
• Modelos de factos – Modelos que representam conexões lógicas (“factos”) entre os conceitos centrais de uma solução e servem como representação do desenvolvimento subsequente de modelos de dados.
• Requisitos funcionais – As capacidades da solução – funções que a solução irá realizar ou permitir que os utilizadores o façam com o software.
• Requisitos não funcionais – Os critérios utilizados para ajuizar a qualidade da solução aparte os seus comportamentos específicos (requisitos de resposta em tempo, capacidade, confiança, usabilidade, etc.)
• Interfaces externos – Os interfaces para outros sistemas e entidades externas dentro do âmbito do projecto.

Esta não é uma sugestão de ordenação, antes a compreensão de que quando se trabalha em requisitos se realizam muitas actividades em simultâneo. Esta regra de economia permitir-nos-á saber com mais confiança qual a linha que estabelece que o trabalho está feito. Os riscos de parar cedo demais e falhar requisitos críticos, ou gastar demasiado tempo num dado conjunto de requisitos (gastando assim tempo valioso) são muito reduzidos quando damos atenção ao «silêncio dos requisitos» (o ponto em que mais informação não está a ajudar a identificar ou refinar requisitos).

Conforme o processo de requisitos se inicia, vai ficando cada vez mais confiante na forma como o problema foi definido quando vai verificando que os stakeholders das diferentes categorias e perfis concordam acerca do que é o problema e como a solução de sucesso irá ser. Passados uns dias e enquanto se vai adicionando e negociando detalhes dos requisitos, pode determinar-se que não houve mudanças no âmbito. Tal permite, por exemplo, declarar que a parte do âmbito do processo de gestão de requisitos está concluída, o que permitirá focar a atenção em outras secções ainda não investigadas.

Saber quando estão concluídos os requisitos para um projecto não é sempre fácil, mas encolher a dimensão dos seus objectivos é uma grande forma de reduzir a luta que sentimos. Ao estabelecer objectivos de menor dimensão e aplicando uma regra de «silêncio dos requisitos» para cada um destes objectivos separadamente, incrementará a capacidade de visão acerca da distância para a meta que se pretende atingir.
Luis Quintino

Documentar Corretamente as Decisões num Projeto de Construção

"Por favor, prossiga com as mudanças."

Essa frase familiar usada por muitos, mas não escrita ou documentada corretamente, pode causar grandes problemas. A documentação das decisões nos projetos de construção não apenas economiza tempo e dinheiro, mas também deve ser uma prática recomendada em todos.

Existem muitas ferramentas e recursos para usar e capturar decisões ou compromissos importantes, mas o que é considerado como tal? Como pode preparar-se para uma reclamação ou situação em potencial que precisa de documentação? Vamos sugerir algumas informações sobre como documentar adequadamente as decisões em projetos de construção.

O que são considerados «documentos importantes»

Para começar, precisamos definir o que podemos considerar como documentos importantes.
 

Plantas, desenhos de engenharia, e-mails, âmbito de trabalho e propostas são itens críticos que devem ser mantidos por muitos anos. Uma ótima maneira de alcançar o processo apropriado de retenção de documentos é usar sistemas para acompanhar as alterações e documentos. No entanto, às vezes é importante acompanhar e entender o contexto do diálogo. As cópias folha de pagamento e as coberturas do seguro também podem fazer parte dessa lista e as cópias originais das mesmas devem ser mantidas por um período maior de tempo.

Documentar as decisões

Em primeiro lugar, é imperativo estabelecer um plano de comunicação para garantir que as partes interessadas certas estejam conscientes e sejam notificadas das decisões. A decisão simples, como pequenas alterações no âmbito, é capturada por meio de comunicações informais, como cartas ou e-mails, antes de serem formalizadas e é assim, evidenciada-
 

Os ajustes do contrato precisam seguir a proposta e o âmbito é esclarecido, debatido e aceite por todas as partes, entre outros itens-chave relativos ao seu projeto. São todas estas coisas que se repetem e que devem ser documentadas.

Documentação de proposta e de Âmbito

Durante o processo de pré-licitação e pré-construção, muitas decisões são tomadas. São recebidos e-mails ou participará em teleconferências sobre quais novos âmbitos ou esclarecimentos são feitos e, assim que possível, precisará adicionar essas alterações ao âmbito e compartilhar essas informações com o dono do projeto ou o seu representante.

O processo de documentação deve conter estimativas, orçamentos, retiradas, informação de preços unitários, ofertas de fornecedores e encargos de trabalho que suportam os ajustes necessários.
 

Documentar as datas de quando você recebeu aprovação para emitir um pedido de compra é importante se precisar comprovar atrasos no material ou nos pedidos de compra associados às decisões. A documentação correta exigida para materiais e compras deve incluir a data de aprovação do material, pedido de compra e um documento com a data de entrega que o fornecedor está a indicar.
 

Para documentar essa decisão, o pedido de compra deve referenciar ou estar vinculado a uma seção específica do contrato e da especificação. Certifique-se de que o aprovador recebe e assina uma cópia, assim como o proponente, com anotação da data de aprovação e da data de entrega.
 

Isto merece uma atenção especial. Toda a vez que uma decisão importante é tomada, é imperativo registar ou produzir um instantâneo do cronograma real, documentando em que momento a decisão foi tomada.
 

Esse instantâneo pode servir como referência para documentar quaisquer mudanças no cronograma que são necessárias após a decisão. Neste ponto, o cronograma deve ser estabelecido e guardado em conjunto com a documentação exigida que fez parte do processo de decisão. Além disso, capture uma comparação entre a programação de pedido de proposta e a programação atual. Recomenda-se documentar duas semanas de antecedência e adicioná-las ao arquivo de mudanças.

Comunicações Diárias

Esta é outra questão importante a considerar durante o processo de documentação. Designe uma pessoa que possa armazenar e acompanhar os registos diários do projeto, notas de campo, condições climáticas, entrega, visitas oficiais do governo e conversas informais.

Esses arquivos devem ser mantidos e devem estar associados a datas e negociações afetadas pelo processo de decisão. Para cada questão, deve ser criado um registo separado e arquivado. Os registos de pedidos de mudança também devem ser mantidos e o registo deve incluir datas de vencimento, responsável, data de aprovação, especificações referenciadas e data de envio. Informações semelhantes devem ser registadas para desenhos, RFIs e especificações de projeto atualizadas.

Os carimbos de tempo normalmente são gravados na maioria dos documentos e os nomes legíveis são necessários para identificar quem recebeu ou assinou o documento, arquivo e / ou material. A hierarquia da equipe do projeto é importante para decidir se um gestor de projeto pode autorizar mudanças ou se precisa obter a aprovação de alguém superior na cadeia de comando.

Todos estes documentos devem ser mantidos e compartilhados com a equipe do projeto por meio de meios eletrônicos, desde que estejam disponíveis no futuro e sejam armazenados e documentados em ordem cronológica e por assunto.

Evidência Física

Com a mais recente tecnologia, recomenda-se gravar uma imagem aérea usando drone junto com fotos e outros vídeos, capturando recursos visuais sobre o status do projeto. Tire fotos em cada local antes do início do trabalho e continue o trabalho concluindo com uma revisão final após a conclusão do trabalho.

Essas fotos devem ser tiradas pelo menos uma vez por semana ou, de preferência, com mais frequência. Certifique-se que revê os documentos do contrato para se certificar de que seguiu o processo contratual para documentar as comunicações do projeto.

A delegação em Projeto

O sucesso na delegação de actividades é essencial para o êxito na gestão de projeto. Contudo, muitas das pessoas envolvidas como líderes em gestão de projeto têm medo da delegação. Eles receiam que, se delegarem, o trabalho este não seja correctamente realizado, que os prazos não sejam alcançados. Eles não confiam na colaboração e no trabalho de equipa e habituaram-se a fazer a maioria das coisas e controlarem directamente tudo o resto.

Mas o problema está na forma como fazemos a delegação – esta tem de ser feita de forma efectiva. A gestão de projetos depende simplesmente da delegação por força da lei da divisão do trabalho: uma pessoa ou equipa focada em uma ou duas atividades específicas é mais eficiente e produtiva que uma pessoa que tenta realizar simultaneamente uma multitude de atividades. Uma pessoa não pode ser todas as coisas para um projecto ou um negócio. Se a delegação for feita de forma adequada com facilidade se conclui que quanto mais de fizer o «laissez faire» em gestão de projeto melhor. No fundo que o melhor gestor é o que gere menos.


O sucesso da gestão de projeto depende da colaboração e do trabalho de equipa e a delegação bem-feita faz com que estes elementos em surjam com sucesso. Quais os cuidados que devemos ter para delegar quando gerimos um projecto?

Não seja vago – se está a gerir um projecto e se vai delegar actividades, deve ser bastante específico acerca do que se espera realizar com a actividade, quando é que deve ser realizado e o que se espera pela realização da actividade. As descrições vagas conduzem a resultados duvidosos e à falha em cumprir os prazos.

Garanta que estabelece prazos realistas – os prazos devem ser realistas e executáveis dentro do tempo pelas pessoas seleccionadas para a actividade. Obviamente, que a delegação envolve escolher as pessoas certas para as actividades certas de acordo com os seus talentos e competências, mas deve ainda assegurar-se que as pessoas que vão ser atribuídas às actividades não terão conflitos ou problemas de agendamento.

Fornecer toda a informação necessária a cada delegação – forneça aos que receberam a delegação uma direção para alcançarem os recursos que possam ser necessários para os tornar mais aptos a concluírem o trabalho em tempo. A colaboração e o trabalho de equipa podem estar entre estes recursos.

Garanta que está disponível como líder da gestão do projecto – os seus delegados devem ser capazes de lhe colocar quaisquer questões ou preocupações acerca do projeto ou das suas atividades. Adicionalmente, deve garantir que eles prestam contas o que exige relatórios periódicos. Contudo, não pressione demais. Um relatório semanal de status deve ser suficiente, desde que o projecto leve mais de uma semana a completar.

Está assumido que se delega actividades em gestão de projeto porque não temos tempo para fazer tudo por nós – Pode até ser que estejamos tão afogados que seja difícil dar instruções explícitas para as atividades. Se é este o caso, deve assegurar-se de delegar numa pessoa como o contacto directo e o gestor do projeto. Será responsabilidade desta pessoa ser o seu «braço direito» e quem terá a responsabilidade de fornecer as especificidades para os outros envolvidos para que possa haver êxito na colaboração e trabalho de equipa. Algumas vezes até a coordenação de uma parte de um projeto deve ser delegada. Se tal ocorrer, tenha o cuidado de realizar a delegação para alguém com experiência de gestão de projectos ou no tipo de trabalho que o projecto irá realizar.

Depois de ter delegado, lembre-se de manter as mãos fora do trabalho o mais possível – Permite aos que estão empenhados um espaço criativo no projeto. Deixe-os aparecer com as suas ideias próprias e fazer mesmo sugestões na forma de fazer as coisas melhor. O fundamental é que se obtenha os resultados desejados e o objetivo do projeto. Claro que a palavra final é sua na aprovação das mudanças às coisas, mas, ao mesmo tempo, não há necessidade de ser autoritário.

Para além dos relatórios de status mensais, implemente um processo de relatórios sobre o projeto – É muito importante ter acesso constante a informação sobre a forma como estão a realizar-se as coisas. Faça isto mas monte um sistema com pro-actividade em que as pessoas envolvidas no projecto se sintam confortáveis a actualizar os registos sem necessidade de marcar uma reunião.

Mantenha um registo pessoal sobre quem está a fazer e que atividade – registe todos os relatórios de status e detalhes de progresso. A manutenção destes registos mantém o seu pensamento sobre o projecto e garante uma dupla verificação dos seus detalhes.

Não se esqueça de louvar e mostrar o crédito quando as actividades são concluídas bem e em tempo ou quando se regista um bom progresso na atividade – os membros da equipa precisam de receber um feedback positivo quando estão a fazer as coisas certas. Não só merecem isso como esse reconhecimento ajuda-os a manter o foco, mantém-nos motivados e ajuda-os a compreender o que devem fazer.

Estes são alguns cuidados a ter quando delegamos actividades em gestão de projeto. A delegação não é uma coisa simples. Exige consideração, compreensão dos requisitos de projecto e um entendimento das capacidades e competências dos que colaboram connosco 
O trabalho de equipa e a colaboração conseguem-se se for feita uma delegação correcta desde o início. Através da delegação conseguimos guiar um projeto até aos seus resultados desejados, sem dores de cabeça, sem excesso de micro-gestão e com todos os envolvidos muito mais contentes e o projeto alcança o que todos desejam – o sucesso.