A Businessballs fez parceria com a Accipio para oferecer módulos de eLearning interactivos áudio-visuais, alinhados com as qualificações reconhecidas internacionalmente (ILM ou CMI). Obtenha pontos de aprendizado para cada eModule de liderança e gerenciamento e obtenha um Prêmio, Certificado ou Diploma de Nível 3 depois de ter se registrado com o corpo de premiação (via Accipio), obtido pontos de aprendizado suficientes e aprovado as atribuições. Aplicam-se taxas de acreditação. Clique aqui para acessar a Academia eLeadership. Gerenciamento de projetos, ferramentas, processos, planos e dicas de planejamento de projetos Aqui estão regras, processos e ferramentas para o planejamento de projetos e gerenciamento de projetos. Projetos grandes ou complexos em grandes organizações muitas vezes exigem algum tipo de patrocínio ou liderança executiva. Isso é comumente chamado de patrocínio de projeto (veja a seção separada sobre o patrocínio do projeto). Embora as habilidades de gerenciamento de projetos sejam obviamente importantes para os gerentes de projeto, curiosamente, os métodos e ferramentas que os gerentes de projeto usam podem ser úteis para todos. Uma tarefa não precisa necessariamente ser chamada de projeto para que os métodos de gerenciamento de projetos sejam muito úteis no planejamento e na implementação. Mesmo a tarefa mais pequena pode se beneficiar do uso de uma técnica ou ferramenta bem escolhida de gerenciamento de projetos, especialmente na fase de planejamento. Qualquer tarefa que requer alguma preparação para alcançar um resultado bem-sucedido, provavelmente será feita melhor usando alguns métodos de gerenciamento de projetos em algum lugar do processo. Os métodos de gerenciamento de projetos podem ajudar no planejamento e gerenciamento de todos os tipos de tarefas, especialmente atividades complexas. O gerenciamento de projetos está principalmente associado ao planejamento e gerenciamento de mudanças em uma organização, mas um projeto também pode ser algo não relacionado a negócios - até mesmo uma situação doméstica, como mudar de casa ou planejar um casamento. Os métodos e ferramentas de gerenciamento de projetos podem, portanto, ser muito mais úteis do que as pessoas assumem. As técnicas de gerenciamento de projetos e as ferramentas de planejamento de projetos são úteis para todas as tarefas nas quais diferentes resultados são possíveis - onde os riscos de problemas e falhas existem - e assim exigem planejamento e avaliação de opções e organização de atividades e recursos para obter um resultado bem-sucedido. Projetos podem ser várias formas e tamanhos, desde o pequeno e direto para extremamente grande e altamente complexo. Em organizações e empresas, o gerenciamento de projetos pode se preocupar com qualquer coisa, particularmente introduzindo ou mudando coisas, em qualquer área ou função, por exemplo: pessoas, pessoal e gestão produtos e serviços materiais, fabricação e produção TI e comunicações planta, veículos, armazenamento de equipamentos , Distribuição, logística edifícios e instalações financiamento, administração, aquisição e desinvestimento compra vendas, venda, marketing desenvolvimento de recursos humanos e formação serviço ao cliente e relações qualidade, saúde e segurança, jurídico e profissional técnico, científico, pesquisa e desenvolvimento desenvolvimento de novos negócios e qualquer coisa Que precisa de planejamento e gerenciamento dentro das organizações. Gestão de projetos bem sucedidos, para projetos grandes ou pequenos, tende a seguir o processo descrito abaixo. Os mesmos princípios, usados seletiva e apropriadamente, também se aplicam a tarefas menores. Técnicas de gerenciamento de projetos não são apenas para gerentes de projeto - eles estão disponíveis para qualquer um usar. Processo de gestão de projectos 1 - acordo especificação precisa (termos de referência) para o projeto Geralmente chamado de termos de referência do projeto, a especificação do projeto deve ser uma descrição precisa do que o projeto pretende alcançar, e os critérios e flexibilidades envolvidas, Escopo, intervalo, saídas, fontes, participantes, orçamentos e prazos (cuidado - veja nota abaixo sobre o planejamento de prazos). Normalmente e antes do estabelecimento formal do projeto, os termos de referência do projeto são produzidos ou pelo menos redigidos em um nível fundamental por um patrocinador do projeto ou executivo responsável do projeto. Muitas vezes, tal descrição inicial do projeto de nível superior inicial (um caso de negócios basicamente) é necessária para que o projeto seja justificado, aprovado e financiado em nível corporativo, antes do início do planejamento detalhado do projeto. O gerente do projeto, tipicamente designado pelo patrocinador do projeto ou pelo executivo responsável, pode estar envolvido, em graus variados, na elaboração da descrição inicial do projeto da empresa ou caso de negócios. Não é incomum que um gerente de projeto seja nomeado não oficialmente para a função de gerenciamento de projetos, aguardando a aprovação corporativa do próprio projeto ea nomeação formal do gerente de projeto. O patrocinador do projeto geralmente é um gerente mais alto ou executivo do que o gerente de projeto, embora não necessariamente o chefe ou gerente de linha superior sênior para que o gerente de projeto normalmente relatórios. Todos os projetos substanciais requerem geralmente um patrocinador de projeto formal ou sênior ou um executivo responsável, embora os projetos menores que fazem parte de deveres convencionais de um gerente e que não requerem a aprovação específica do conselho ou da corporação, não podem exigir um patrocinador de projeto como tal, A responsabilidade pelo projeto eo gerente de projeto pertence ao gerente / executivo de relatórios de linha de atuação normal. Normalmente, o gerente de projeto deve consultar outros (especialmente o patrocinador do projeto) e então concordar com a especificação detalhada do projeto com os superiores e / ou autoridades relevantes. A especificação pode envolver vários rascunhos antes de ser acordado. Uma especificação de projeto é essencial na medida em que cria uma responsabilidade mensurável para qualquer pessoa que deseje, a qualquer momento, avaliar como o projeto está indo ou seu sucesso na conclusão. Os termos de referência do projeto também fornecem uma disciplina e um quadro essenciais para manter o projeto no caminho certo e preocupados com os objetivos e parâmetros acordados originalmente. Uma especificação de projeto devidamente formulada e acordada também protege o gerente de projeto de ser responsabilizado por questões que estão fora do escopo original do projeto ou além do controle do gerente de projeto. Esta é a etapa para acordar condições especiais ou exceções com aqueles em autoridade. Uma vez que você publicou os termos de referência que você criou um conjunto muito firme de expectativas pelas quais você será julgado. Então, se você tem alguma preocupação, ou quer renegociar, agora s o tempo para fazê-lo. Os maiores projetos podem exigir várias semanas para produzir e concordar termos de referência do projeto. A maioria dos projetos de negócios normais, porém, exigem alguns dias pensando e consultando para produzir uma especificação de projeto adequado. Estabelecer e aceitar uma especificação de projeto é um processo importante, mesmo que sua tarefa seja simples. Um modelo para uma especificação de projeto: Descreva finalidade, objetivos e entregas. Parâmetros estatais (prazos, orçamentos, alcance, âmbito, território, autoridade). Estado de pessoas envolvidas e a forma como a equipe vai trabalhar (freqüência de reuniões, processo de tomada de decisão). Estabelecer pontos de ruptura para rever e verificar o progresso e como o progresso e os resultados serão medidos. Separadamente, o acrônimo BOSCARDET fornece uma estrutura de exemplo útil para títulos / seções de Termos de Referência: Antecedentes, Objetivos, Escopo, Restrições, Premissas, Relatórios, Dependências, Estimativas, Prazos. Esta estrutura não contém um cabeçalho específico para custos / orçamentos - estas considerações podem ser incluídas dentro de restrições ou estimativas. Como os projetos (e outras atividades que exigem termos de referência) variam consideravelmente, não há uma estrutura universal padrão para um documento de Termos de Referência. A responsabilidade cabe ao gerente de projeto ou ao líder assegurar que todas as questões relevantes e necessárias sejam incluídas, e esta interpretação local tende a implicar os cabeçalhos de TOR ea estrutura do documento. Brainstorming pode ser um processo útil pelo qual todos os critérios de referência relevantes podem ser identificados e estruturados. As organizações podem ter estruturas TOR padrão, como o exemplo BOSCARDET, que é sensato usar quando aplicável, atento aos riscos de omissão ou complicação excessiva que podem surgir quando seguindo a prática padrão. Consulte também Termos de referência na seção do dicionário de negócios. 2 - planejar o projeto Planejar as várias etapas e atividades do projeto. Sempre que possível (e certamente quando necessário) envolver sua equipe no planejamento. Uma dica útil é trabalhar para trás a partir do objectivo final, identificando todas as coisas que precisam ser colocadas no lugar e feito, em ordem inversa. Além disso, a partir dos primórdios do projeto, use brainstorming (observando idéias e pontos aleatoriamente - tipicamente com uma equipe de projeto), para ajudar a reunir pontos e questões e explorar inovações e idéias. Diagramas de espinha de peixe também são úteis para brainstorming e identificar fatores causais que poderiam ser esquecidos. Para projetos complexos, ou quando você não tem experiência das questões, envolver outras pessoas no processo de brainstorming. Posteriormente, trata-se de colocar as questões na ordem correta e estabelecer relações e vínculos entre cada questão. Projetos complexos terão um número de atividades correndo em paralelo. Algumas partes do projeto precisarão de outras partes do projeto para serem concluídas antes que elas possam começar ou progredir. Tais partes interdependentes de um projeto precisam ser cuidadosamente consideradas e planejadas. Alguns projectos exigirão uma fase de viabilidade antes da conclusão de um plano detalhado. Gráficos de Gantt e Análise de Caminho Crítico Os fluxogramas são duas ferramentas comumente utilizadas para o planejamento detalhado do gerenciamento de projetos, permitindo agendamento, cálculo de custos e orçamentação e outras finanças e gerenciamento de projetos e relatórios. Veja também o patrocínio do projeto para entender como o patrocínio do projeto pode ser integrado com as responsabilidades do planejador para o gerente do projeto. Os prazos e os custos do projeto A maioria dos projetos chega tarde - é exatamente assim - então não planeje um prazo que seja excessivamente ambicioso. Idealmente plano para alguns derrapagem. Se você recebeu um prazo fixo, planeje atendê-lo mais cedo e volte a trabalhar nessa data anterior. Construir algum deslizamento ou margem de manobra em cada fase do projeto. Err do lado de cuidado onde você pode. Projetos que deslizam para trás e são entregues tarde, ou que executar sobre o orçamento ou não cumprir outras exigências financeiras muitas vezes causam problemas significativos. Muitos planejadores são colocados sob pressão para entregar projetos mais cedo e mais custo-efetivamente do que é realista. Ambição e visando alto são boas atitudes, mas o planejamento sem a devida prudência e responsabilidade é estúpido. Investidores e executivos raramente questionam um plano ambicioso, mas rapidamente tomarão decisões muito cruéis quando qualquer projeto excessivamente ambicioso começar a falhar. Exercitar um pouco de realismo no início de um projeto sobre finanças e prazos pode salvar uma enorme quantidade de problemas mais tarde. A equipe do projeto Outra parte importante da fase de planejamento é escolher sua equipe. Tome muito cuidado, especialmente se você tiver membros da equipe imposto sobre você pelo brief do projeto. Selecionar e ganhar o compromisso dos melhores membros da equipe - seja diretamente empregado, freelance, contratantes, fornecedores, consultores ou outros parceiros - é crucial para a qualidade do projeto ea facilidade com que você é capaz de gerenciá-lo. Geralmente tente estabelecer sua equipe o mais rápido possível. Identificar ou nomear uma ou duas pessoas, mesmo durante os termos de referência fase é possível, por vezes. A nomeação da equipe precoce maximiza sua propriedade e buy-in para o projeto, e maximiza o que eles podem contribuir. Mas tenha muito cuidado em nomear pessoas antes de ter certeza de quão boas elas são, e não até que elas tenham se comprometido com o projeto em termos que sejam claramente entendidos e aceitáveis. Não imagine que as equipes precisam estar cheias de membros da equipe de projeto pagos e oficiais. Alguns dos membros mais valiosos da equipe são assessores informais, mentores, ajudantes, que não querem nada além de estar envolvido e algumas palavras de agradecimento. Gestão de projetos em um orçamento apertado pode ser um negócio solitário - obter alguma ajuda de pessoas boas que você pode confiar, independentemente do orçamento. Para planejar e gerenciar grandes projetos complexos com várias atividades paralelas e dependentes, você precisará criar uma Análise de Caminho Crítico e uma planilha em MS Excel ou equivalente. A Análise de caminho crítico mostrará a ordem em que as tarefas devem ser executadas ea importância relativa das tarefas. Algumas tarefas podem parecer pequenas e insignificantes quando elas podem realmente ser extremamente influentes, permitindo atividades muito maiores para prosseguir ou dar melhores resultados. Um gráfico de Gantt é uma maneira útil de mostrar blocos de atividades ao longo do tempo ea um custo determinado e para gerenciar o projeto e seus custos ao longo do caminho. Vários softwares de gerenciamento de projetos estão disponíveis, muitos dos quais são úteis, mas antes de tentar, você deve entender e se concentrar no desenvolvimento das habilidades de gerenciamento de projeto puro, que são descritos neste processo. O melhor software do mundo não vai ajudá-lo se você não pode fazer as coisas básicas. Consulte também o patrocínio do projeto para uma explicação detalhada de como o papel do patrocinador do projeto pode estar envolvido com a equipe do projeto. Ferramentas de gerenciamento de projetos Aqui estão exemplos e explicações de quatro ferramentas comumente usadas no planejamento de projetos e gerenciamento de projetos, a saber: Brainstorming, Diagramas de Fishbone, Diagramas de Fluxo de Análise de Caminho Crítico e Gráficos de Gantt. Além disso, consulte separadamente a modelagem de processos de negócios e o gerenciamento de qualidade. Que contêm ferramentas e métodos relacionados além dos principais modelos de gerenciamento de projetos mostrados abaixo. As ferramentas aqui têm suas forças e propósitos particulares, resumidas como um guia básico na matriz abaixo. Brainstorming Brainstorming é geralmente a primeira fase criativa crucial do processo de gerenciamento de projetos e planejamento de projeto. Veja o método de brainstorming em detalhes e explicado separadamente, porque muitas outras aplicações úteis fora do gerenciamento de projetos. Ao contrário da maioria das habilidades e métodos de gerenciamento de projetos, as primeiras etapas do processo de brainstorming é idealmente uma técnica de pensamento livre e aleatória. Conseqüentemente pode ser negligenciado ou under-utilizado porque não uma aproximação natural para muitos povos cujas forças principais estão nos sistemas e nos processos. Consequentemente, esta etapa do processo de planejamento do projeto pode se beneficiar de ser facilitada por um membro da equipe capaz de gerenciar tal sessão, especificamente para ajudar pessoas muito organizadas a pensar de forma aleatória e criativa. Diagramas de espinha de peixe Os diagramas de espinha de peixe são usados principalmente na detecção de falhas de gerenciamento de qualidade e na melhoria de processos de negócios, especialmente na fabricação e produção, mas o modelo também é muito útil em planejamento de gerenciamento de projetos e gerenciamento de tarefas em geral. Dentro do gerenciamento de projetos, os diagramas de espinha de peixe são úteis para o planejamento precoce, principalmente quando se coleta e organiza fatores, por exemplo durante a sessão de brainstorming. Os diagramas de espinha de peixe são muito bons para identificar fatores ocultos que podem ser significativos para permitir atividades maiores, áreas de recursos ou partes de um processo. Os diagramas de espinha de peixe não são bons para agendar ou mostrar fatores interdependentes de tempo crítico. Diagramas de espinha de peixe também são chamados diagramas de causa e efeito e diagramas de Ishikawa, depois de Kaoru Ishikawa (1915-1989), um professor japonês especializado em gestão de qualidade industrial e engenharia que inventou a técnica na década de 1960. O diagrama de Ishikawa tornou-se conhecido como um diagrama de espinha de peixe, obviamente, porque parece uma espinha de peixe. Um diagrama de espinha de peixe tem uma espinha central correndo da esquerda para a direita, em torno da qual é construído um mapa de fatores que contribuem para o resultado final (ou problema). Para cada projeto, as principais categorias de fatores são identificadas e mostradas como os principais ossos que levam à coluna vertebral. Em cada categoria podem ser desenhados elementos primários ou fatores (mostrados como P no diagrama), e neles podem ser desenhados elementos secundários ou fatores (mostrados como S). Isso é feito para cada categoria, e pode ser estendido para fatores de terceiro ou quarto nível, se necessário. O diagrama acima é muito simples. Normalmente, os diagramas de espinha de peixe têm seis ou mais ossos principais alimentados na coluna vertebral. Outros fatores principais da categoria podem incluir o ambiente, a gerência, os sistemas, o treinamento, o Legal, etc. As categorias usadas em um diagrama do fishbone devem ser o que quer que faz o sentido para o projeto. Vários conjuntos de categorias padrão existem para diferentes aplicações industriais, no entanto, é importante que a estrutura escolhida seja adequada para a sua própria situação, em vez de tomar um conjunto padrão de títulos de categoria e esperando que ele se encaixa. Em um nível simples, o diagrama de espinha de peixe é um modelo e uma ferramenta de planejamento muito eficazes - especialmente para mapear toda uma operação. Quando um diagrama de espinha de peixe é usado para o planejamento do projeto, é claro que o Efeito é mostrado como um objetivo ou resultado ou resultado, não um problema. O termo do problema é usado no diagnóstico de falhas e na resolução de problemas de gerenciamento de qualidade. Alguns diagramas de espinha de peixe podem tornar-se muito complexos, o que é comum em áreas de gestão de qualidade especializadas, especialmente onde os sistemas são computadorizados. Este modelo eo diagrama de análise de caminho crítico são semelhantes aos diagramas ainda mais complexos usados na modelagem de processos de negócios em áreas de planejamento de negócios e melhoria de processos de negócios. Análise de caminho crítica do projeto (diagrama de fluxo ou gráfico) A análise de caminho crítico soa muito complicada, mas é um método muito lógico e eficaz para planejar e gerenciar projetos complexos. Uma análise de caminho crítico normalmente é mostrada como um fluxograma, cujo formato é linear (organizado em uma linha) e, especificamente, uma linha de tempo. A Análise de Caminho Crítico também é chamada de Método de Caminho Crítico - é a mesma coisa - e os termos são geralmente abreviados, para CPA e CPM. Uma ferramenta comumente usada na Análise de Caminho Crítico é o PERT (Programa / Programa / Avaliação do Projeto e Técnica de Revisão), que é um método especializado para identificar atividades e eventos relacionados e interdependentes, especialmente onde um projeto grande pode conter centenas ou milhares de elementos conectados. PERT não é normalmente relevante em projetos simples, mas qualquer projeto de tamanho e complexidade consideráveis, particularmente quando os tempos e as questões de interdependência são cruciais, podem se beneficiar da análise detalhada permitida pelos métodos PERT. A análise PERT geralmente se alimenta da Análise do Caminho Crítico e de outros sistemas mais amplos de gerenciamento de projetos, como os mencionados aqui. Os diagramas de fluxo da Análise do Caminho Crítico são muito bons para mostrar fatores interdependentes cujos cronogramas se sobrepõem ou coincidem. Eles também permitem que um plano seja agendado de acordo com uma escala de tempo. Os fluxogramas de análise de trajetória crítica também permitem o cálculo de custos e o orçamento, embora não tão facilmente quanto os gráficos de Gantt (abaixo), e também ajudam os planejadores a identificar elementos causais, embora não tão facilmente quanto os diagramas de espinha de peixe. Isto é como criar uma Análise de Caminho Crítico. Como exemplo, o projeto é simples - fazer um pequeno-almoço frito. Primeiro, anote todas as questões (recursos e atividades em uma ordem grosseira), novamente por exemplo: Montar louça e utensílios, montar ingredientes, preparar equipamentos, fazer torradas, fritar salsichas e ovos, grelhar bacon e tomates, servir. Note que algumas dessas atividades devem acontecer em paralelo - e crucialmente são interdependentes. Ou seja, se você tentou fazer um pequeno-almoço frito fazendo uma tarefa de cada vez, e um após o outro, as coisas iriam dar errado. Certas tarefas devem ser iniciadas antes das outras, e certas tarefas devem ser completadas para que outros possam começar. As placas precisam de aquecimento enquanto outras actividades estão a decorrer. O brinde precisa ser torrada enquanto as salsichas são frying, e ao mesmo tempo o bacon e salsichas estão sob a grelha. Os ovos precisam ser frito passado. Uma Análise de Caminho Crítico é uma representação diagramática do que precisa ser feito e quando. Escalas de tempo e custos podem ser aplicados a cada atividade e recurso. Aqui está a Análise de Caminho Crítico para fazer um pequeno-almoço frito: Este exemplo de Análise de Caminho Crítico abaixo mostra apenas algumas atividades ao longo de alguns minutos. Projetos comerciais normais veriam a análise se estender várias vezes mais do que este exemplo, ea linha de tempo seria baseada em semanas ou meses. É possível usar o MS Excel ou uma planilha similar para criar uma Análise de Caminho Crítico, que permite que os totais financeiros e os totais de tempo sejam planejados e rastreados. Vários softwares de gerenciamento de projetos especializados permitem a mesma coisa. Cuidado com o passar de semanas sobre as complexidades da modelagem de computador, quando nos estágios iniciais especialmente, um diagrama cuidadosamente desenhado mão - que não requer nenhum treinamento de computador em tudo - pode colocar 90 do pensamento e estrutura no lugar. (Veja os detalhes sobre a mais incrível ferramenta de planejamento e comunicação já inventada e disponível por apenas uma pequena fração do preço de todas as alternativas.) Análise do caminho crítico do projeto diagrama de fluxo diagramas de exemplo de Gantt Gráficos de Gantt Ferramentas de gerenciamento de projetos extremamente úteis. O gráfico de Gantt é nomeado após o engenheiro e consultor americano Henry Gantt (1861-1919) que inventou a técnica nos 1910s. Os gráficos de Gantt são excelentes modelos para agendar e orçamentar e para relatar e apresentar e comunicar planos de projetos e progredir facilmente e rapidamente, mas como regra os Gráficos de Gantt não são tão bons quanto um Diagrama de Fluxo de Análise de Caminho Crítico para identificar e mostrar fatores interdependentes, Ou para mapear um plano de e / ou em todos os seus elementos causais ou contribuintes detalhados. Você pode construir um gráfico de Gantt usando MSExcel ou uma planilha similar. Cada atividade tem uma linha separada. Criar uma linha de tempo para a duração do projeto (o exemplo de café da manhã mostra minutos, mas normalmente você usaria semanas, ou para grandes projetos de longo prazo, meses). Você pode codificar em cores os blocos de tempo para denotar o tipo de atividade (por exemplo, intenso, observando breve, gerenciado diretamente, delegado e esquerdo para executar, etc.) Você pode agendar revisão e inserir pontos de interrupção. No final de cada linha, você pode mostrar quantas colunas de custo para as atividades que você precisa. O exemplo de café da manhã mostra apenas o custo de capital dos itens consumíveis e um custo de receita para mão-de-obra e combustível. Um gráfico de Gantt como este pode ser usado para acompanhar o progresso de cada atividade e como os custos estão sendo executados. Você pode mover os blocos de tempo em torno de relatório sobre real versus planejado, e para re-agendar, e criar novas atualizações de plano. As colunas de custos podem mostrar planos e valores reais e variações e calcular os totais, médias, proporções, etc. que você precisa. Os Gráficos de Gantt são provavelmente os mais flexíveis e úteis de todas as ferramentas de gerenciamento de projetos, mas lembrem-se de que não mostram com muita facilidade ou obviamente a importância e interdependência de atividades paralelas relacionadas e não mostrarão, obviamente, a necessidade de completar uma tarefa antes de outra Pode começar, como uma Análise de Caminho Crítico fará, então você pode precisar de ambas as ferramentas, especialmente na fase de planejamento, e quase certamente para grandes projetos complexos. As ferramentas de planejamento do projeto naturalmente se tornam usadas também para relatórios subseqüentes de projetos, apresentações, etc. e você tornará a vida mais fácil para todos se usar formatos que as pessoas reconheçam e encontrem familiares. Existe agora uma vasta gama de sistemas / software informatizados para a gestão e o planeamento do projecto e continuam a ser desenvolvidos novos métodos. É uma área de alta inovação, com muito espaço para melhorias e desenvolvimento. Congratulo-me com sugestões de sistemas particularmente bons, especialmente se barato ou gratuito. Muitas organizações desenvolvem ou especificam ferramentas computadorizadas específicas, por isso é uma boa idéia procurar conselhos relevantes locais e exemplos de melhores práticas antes de decidir o melhor sistema de gerenciamento de projeto computadorizado para sua própria situação. Sou grato a I Kerr que escreveu (out 2013):. Eu ensino um módulo sobre gerenciamento de projetos como parte de um programa de voluntariado e encontrei a ferramenta gratuita GanttProject (ganttproject. biz/) para ser muito eficaz e amigável. De fato GanttProject parece ser excelente software livre. Eu não testá-lo totalmente assim que apreciaria relatórios adicionais sobre ele. Planejamento financeiro do projeto e relatórios Para projetos envolvendo mais do que dinheiro pequeno você provavelmente precisará de uma planilha para planejar e relatar despesas planejadas e reais. Use o MSExcel ou similar. Contabilidade financeira para pequenos projetos às vezes pode ser gerenciado usando o Gantt Chart do projeto. Projetos grandes são susceptíveis de exigir algum tipo de requerem sistema de contabilidade dedicada, embora concebivelmente Gantt Charts e contas de gestão financeira pode ser facilmente administrado dentro de um sistema de planilha dado conhecimentos suficientes. Se você não sabe como montar um plano financeiro básico, obter alguma ajuda de alguém que faz, e certifique-se de trazer uma boa amigável, pessoa financeira flexível em sua equipe - é uma função-chave do gerenciamento de projetos e se você puder T gerenciar os processos financeiros de sua auto você precisa ser capaz de confiar completamente em quem faz isso por você. A planilha deve permitir que você planeje, administre e relate as finanças detalhadas de seu projeto. Crie uma linha de custo para a atividade de despesa principal e divida-a em elementos individuais. Crie um sistema para alocar faturas de entrada para as atividades corretas (suas pessoas compradas não sabem a menos que você diga), e mostrando quando os custos atingiram a conta do projeto. Estabelecer condições claras de pagamento com todos os fornecedores e cumpri-los. Projetos desenvolvem problemas quando os membros da equipe ficam satisfeitos Descontente, não, ou atraso de pagamento é a principal causa de insatisfação. Lembre-se de definir algum orçamento de lado para contingências - você quase certamente vai precisar dele. Veja também o patrocínio do projeto. Para detalhes de como esse papel pode estar envolvido com aspectos de planejamento de projeto e relatórios. Planejamento de contingência do projeto Planejar e antecipar o imprevisto, ou a possibilidade de que as coisas não vão como esperado, é chamado de planejamento de contingência. O planejamento de contingência é vital em qualquer tarefa quando resultados e resultados não podem ser absolutamente garantidos. Muitas vezes um orçamento de contingência precisa ser planejado, pois geralmente há custos associados. O planejamento de contingência é sobre a preparação de ações de recuo e assegurar que a margem de manobra para tempo, atividade e recurso exista para corrigir ou substituir planos de primeira escolha. Um simples plano de contingência para o pequeno-almoço frito seria planejar a possibilidade de quebrar a gema de um ovo, caso em que o recurso sobressalente (ovos) deve ser orçamentado e disponível se necessário. Outro pode ser preparar alguns hash-browns e cogumelos no evento que qualquer um dos comensais são vegetarianos. Pode ser difícil antecipar com precisão que contingência planejar em projetos complexos de longo prazo, caso em que apenas um orçamento de contingência é fornecido, a ser alocado mais tarde quando e se necessário. 3 - comunicar o plano do projeto à sua equipe Isso serve para dois propósitos: informa às pessoas o que está acontecendo, e obtém apoio essencial, acordo e compromisso. Se seu projeto é complexo e envolve uma equipe, então você deve envolver a equipe no processo de planejamento para maximizar o buy-in, a propriedade e, portanto, a prestação de contas. O seu projecto também irá beneficiar da entrada e consulta de pessoas relevantes numa fase inicial. Considere também a melhor forma de comunicar os objetivos e a abordagem de seu projeto a outros em sua organização e em uma rede mais ampla. Sua equipe de projeto pode se estender mais amplamente do que você pode imaginar. Considere todas as possíveis partes interessadas - aqueles que têm interesse em seu projeto e as áreas que ela toca e precisa atrair apoio ou tolerância. Envolvimento e comunicação são vitais para a cooperação e apoio. Falhar em comunicar às pessoas (que não têm grande contribuição, mas cuja cooperação é crucial) é uma razão comum para despertar suspeitas e objeções, defensiva ou resistência. Veja também o patrocínio do projeto. Para mais pormenores sobre a forma como esse papel pode envolver a comunicação com o ambiente mais amplo e as partes interessadas. 4 - concordar e delegar ações do projeto Seu plano terá identificado os responsáveis por cada atividade. As atividades precisam ser muito claramente descritas, incluindo todos os parâmetros relevantes, prazos, custos e entregas. Use o acrônimo SMART para ajudá-lo a delegar tarefas corretamente. Consulte as dicas e processos de delegação. Usar métodos de delegação adequados é vital para o gerenciamento de projetos bem sucedido envolvendo equipes. Quando as tarefas delegadas falham, isso geralmente ocorre porque elas não foram explicadas claramente, concordaram com a outra pessoa ou foram suportadas e verificadas enquanto estavam em andamento. Portanto, publique o plano completo para todos na equipe e considere cuidadosamente como delegar tarefas de médio a longo prazo à luz dos recursos de planejamento avançado dos membros da equipe. Projetos complexos de longo prazo precisam ser planejados com mais detalhes, e um grande cuidado deve ser tomado na delegação e apoio deles. Somente delegar tarefas que passam o teste SMART. Outros materiais úteis para ajudar a entender a delegação da equipe são o Tannenbaum eo Schmidt Continuum. E grupo de Tuckman que forma / que executa modelo. O modelo Johari Window é também um excelente quadro de revisão para verificar rapidamente ou lembrar sobre a conscientização mútua entre os membros da equipe em grandes projetos complexos, onde há freqüentemente um risco de fragmentação do projeto e pessoas fazendo o seu próprio bem em isolamento bem-aventurado - Melhores projetos planejados. 5 - gerenciar, motivar, informar, encorajar, capacitar a equipe do projeto Gerenciar a equipe e as atividades nas reuniões. Comunicar, apoiar e ajudar com as decisões (mas não torná-las para as pessoas que podem fazê-las para si). Louvor em voz alta culpa suavemente. (Uma máxima maravilhosa atribuída a Catarina, a Grande). Um dos grandes desafios para um gerente de projeto é decidir quanto de liberdade para dar para cada atividade delegada. Parâmetros apertados e muita verificação são necessários para pessoas inexperientes que gostam de instruções claras, mas essa abordagem é o beijo da morte para pessoas experientes, empreendedoras e criativas. Eles precisam de um prazo mais amplo, mais liberdade e menos checagem. Gerencie essas pessoas pelos resultados que eles obtêm - não como eles obtê-los. Procure diferenças em personalidade e estilos de trabalho em sua equipe. Misunderstanding estilos pessoais podem ficar no caminho da cooperação da equipe. Seu papel aqui é ativar e traduzir. Reuniões cara a cara, quando você pode reunir os membros da equipe, geralmente são a melhor maneira de evitar problemas e relacionamentos tornando-se personalizado e emocional. Comunicar progressos e sucessos regularmente a todos. Dê às pessoas em sua equipe os aplausos, particularmente quando alguém alto expressa satisfação - nunca, nunca aceita aplausos você mesmo. Conversely - you must take the blame for anything that goes wrong - never dump (your problems or stresses) on anyone in your team. As project manager any problem is always ultimately down to you anyway. Use empathy and conflict handling techniques. and look out for signs of stress and manage it accordingly. A happy positive team with a basic plan will outperform a miserable team with a brilliant plan, every time. 6 - check, measure, and review project performance adjust project plans inform project team and others Check the progress of activities against the plan. Review performance regularly and at the stipulated review points, and confirm the validity and relevance of the remainder of the plan. Adjust the plan if necessary in light of performance, changing circumstances, and new information, but remain on track and within the original terms of reference. Be sure to use transparent, pre-agreed measurements when judging performance. (Which shows how essential it is to have these measures in place and clearly agreed before the task begins.) Identify, agree and delegate new actions as appropriate. Inform team members and those in authority about developments, clearly, concisely and in writing. Plan team review meetings. Stick to the monitoring systems you established. Probe the apparent situations to get at the real facts and figures. Analyse causes and learn from mistakes. Identify reliable advisors and experts in the team and use them. Keep talking to people, and make yourself available to all. See also project sponsorship. to appreciate the higher-level responsibilities for monitoring and reporting of a project s progress, status, implications, etc. 7 - complete project review and report on project give praise and thanks to the project team At the end of your successful project hold a review with the team. Ensure you understand what happened and why. Reflect on any failures and mistakes positively, objectively, and without allocating personal blame. Reflect on successes gratefully and realistically. Write a review report, and make observations and recommendations about follow up issues and priorities - there will be plenty. Where a project sponsor is involved it is reasonable for this role to be responsible for top-level reporting/review, and where applicable recognizing and rewarding the successful project manager and team too. 8 - follow up - train, support, measure and report project results and benefits Traditionally this stage would be considered part of the project completion, but increasingly an emphasised additional stage of project follow-up is appropriate. This is particularly so in very political environments, and/or where projects benefits have relatively low visibility and meaning to stakeholders (staff, customers, investors, etc), especially if the project also has very high costs, as ICT projects tend to do. ICT (information and communications technology) projects often are like this - low visibility of benefits but very high costs, and also very high stress and risk levels too. Project management almost always involves change management too, within which it s very important to consider the effects of the project on people who have to adapt to the change. There is often a training or education need. There will almost certainly be an explanation need, in which for example methods like team briefing have prove very useful. Whatever, when you are focused on project management it is easy to forget or ignore that many people are affected in some way by the results of the project. Change is difficult, even when it is good and for right reasons. Remembering this during and at the end of your project will help you achieve a project that is well received, as well as successful purely in project management terms. And again, see the relevance and typical responsibilities of project sponsorship within the overall successful conception, management and delivery of a project. Someone once said Don t you love it when a plan comes together As project manager, to be at the end of a project and to report that the project plan has been fully met, on time and on budget, is a significant achievement, whatever the project size and complexity. The mix of skills required are such that good project managers can manage anything. amusing project management analogies To the optimist, the glass is half full. To the pessimist, the glass is half empty. To the project manager, the glass is twice as big as it needs to be. A clergyman, a doctor and a project manager were playing golf together one day and were waiting for a particularly slow group ahead. The project manager exclaimed, What s with these people We ve been waiting over half and hour It s a complete disgrace. The doctor agreed, They re hopeless, I ve never seen such a rabble on a golf course. The clergyman spotted the approaching greenkeeper and asked him what was going on, What s happening with that group ahead of us They re surely too slow and useless to be playing, aren t they The greenkeeper replied, Oh, yes, that s a group of blind fire-fighters. They lost their sight saving our clubhouse from a fire last year, so we always let them play for free anytime. The three golfers fell silent for a moment. The clergyman said, Oh dear, that s so sad. I shall say some special prayers for them tonight. The doctor added, rather meekly, That s a good thought. I ll get in touch with an ophthalmic surgeon friend of mine to see if there s anything that can be done for them. After pondering the situation for a few seconds, the project manager turned to the greenkeeper and asked, Why can t they play at night And this (thanks G Bee). A project manager was out walking in the countryside one day when a frog called out to him. He bent down, picked up the frog and put it in his pocket. The frog called out again, saying, If you kiss me I shall turn me back into a beautiful princess, and I ll stay with you for a week as your mistress. The project manager took the frog out of his pocket, smiled at it, and put it back into his pocket. The frog called out once more, If you kiss me and turn me back into a princess, I ll stay with you for as long as you wish and do absolutely anything that you want. Again the Project manager took the frog out of his pocket, smiled at it and put it back. Finally, the frog demanded, What s the matter You can turn me back into a beautiful princess, and I ll stay with you for ever and do anything you want. Why won t you kiss me to which the project manager replied, Understand, I m a project manager. I simply don t have time for a girlfriend, but a talking frog. that s cool. see also (With thanks to Ron Rosenhead of The Project Agency for these four project management materials) authorship/referencing The materials linked from this page that are contributed by The Project Agency are Ron Rosenhead. alan chapman 1995-2014 Silicon Beach Training PRINCE2 Project Initiation Document Template With a Project Initiation Document (PID) you define the project s scope and direction and use it as the basis for its authorisation, management and assessing its success. The document details all the foreseeable areas of the project, such as goals, scope, risks, controls and budget. The PID must contain several pieces of information that are vital to the success of a project. If these areas aren t defined clearly from the outset, there is a high chance that the project will fail. The PID should cover the following areas: Our PRINCE2 Foundation covers all your need to learn to use a PID and other PRINCE2 tools and techniques. We also offer a full 5-day PRINCE2 Practitioner course for those who want to cover both stages and take both exams. You can download a Project Initiation Document template in our PRINCE2 downloads section (see the PRINCE2 project templates). We will look in a bit more depth at each of these ares and what information you need to include. Project Definition The project definition explains what the project needs to achieve, including: Project Background why do we need this project, what events have caused the need for the project Project objectives desired outcomes describe the specific outcomes of the project and what the expected results will be following project completion. Project scope and exclusions detail about the boundaries for this project. Specifically what is included and what isn t included to avoid any confusion or misunderstandings with stakeholders further down the line. Constraints and assumptions Restrictions or limitations either external or internal to the project that you have to factor into the project that are beyond your control What assumptions are you making that will have a bearing on the project Users and interested parties PRINCE2 defines Users as those who, after the project is complete will use the products to enable them to gain the intended benefits. Other interested parties could include suppliers and sponsors. Interfaces Describe here what interfaces and interactions the project will have, either internal or external to your company, as well as links to other related projects. Project Approach In this section you must describe how the project will deliver the required solution, according to the business case. You should also list the skills required to achieve the project s aims. Business Case A vital part of any project is it s continued business justification. This justification is described in the Business Case which should cover estimated costs, risks and the expected benefits. The Business Case may often be a separate document that should be referenced here. Project Management Team Structure In this section you should define the structure of the Project Team, defining the different levels of management, this is usually done in the form of a diagram. See the image below for an example: Role Descriptions Within PRINCE2 each member of the team has defined roles and responsibilities. The Roles defined in the previous Project Management Team Structure section should be described here. Each project will differ depending on the structure of the project but will likely include the following Roles: Project Board Business /Customers / Suppliers interests (represented on the Project Board) Project Assurance Project Manager Team Manager Project Support Possible Change Authority Quality Management Strategy The Quality Management Strategy describes how the project will meet the customer s quality expectations and identifies with whom the responsibility for quality lies. Like the Business Case this will often be contained in a separate document. Configuration Management Strategy The Configuration Management Strategy should be created during the Initiating a Project stage. It defines the approach taken to identify, track and protect the project assets so the Project Manager can track their status as they evolve throughout the project lifecycle. It also defines the issue and change control procedures that will be applied to the project. Risk Management Strategy The Risk Management Strategy should describe the techniques that will be used to Identifying, assessing and control risk during the project. The Risk Management Strategy should be well documented so all members of the project team are aware how it will be managed during all the projects activities and who is responsible for identifying the risks. Communication Management Strategy Lack of communication between the project team is a common reason for project failure. The Project Manager is responsible for ensuring that all stakeholders are aware of the projects status. The Communication Management Strategy defines the method and frequency of communication between all interested parties from the Project Board to the Project Support Team. Project Plan In order to gain authorisation for the project, the costs involved and timescales must be defined. Depending on the scale of the project, the different products, activities and resources required by the project should be defined so they can be tracked by the Project Manager, this is documented in the project plan which acts as a baseline to monitor the progress of the project. It is the Project Managers responsibility to update the Project Plan throughout the project s lifecycle and inform the Project Board of any changes that may affect the overall outcomes. Project Controls Projects need to be controlled so that appropriate and informed decision making can be made. Definition of the Stage boundaries for this decision making will be identified, tolerances that have been agreed for the project and how these are monitored and reported should be included here. Tailoring of PRINCE2 As every project is different, it is usual that PRINCE2 will be tailored to suit the nature of the project. Whilst the basic principles of PRINCE2 should be used, the project management team can adapt the method to suit that specific project. This section should document how PRINCE2 will be tailored, for example the Roles, Themes or Processes can be amended to suit the scale of the project. Similar posts you may like: Tags Andy Trainer Definitive Guide to Develop a Good Test Strategy Document with These 7 Simple Steps What is Test Strategy A strategy plan for defining testing approach, what you want to accomplish and how you are going to achieve it. This document removes all uncertainty or vague requirement statements with a clear plan of approach for achieving the test objectives. Test strategy is one of the most important documents for QA team. Writing it effectively is a skill every tester should achieve in their career. It initiates your thought process which helps to discover many missing requirements. Thinking and test planning activities help team to define testing scope and test coverage. It helps test managers to get clear state of the project at any point. The chances of missing any test activity are very low when there is a proper test strategy in place. Test execution without any plan rarely works. I know teams who write strategy document but never refer it back while test execution. Testing strategy plan must be discussed with whole team so that the team will be consistent on approach and responsibilities. In tight deadlines, you can t just waive any testing activity due to time pressure. At least it must go through a formal process before doing so. Test Strategy vs. Test Plan: Over the years, I see a lot of confusion between these two documents. So let s start with basic definitions. Generally it doesn t matter which comes first. Test planning document is a combination of strategy plugged with overall project plan. According to IEEE Standard 829-2008, strategy plan is a sub item of test plan. Every organization has their own standards and processes to maintain these documents. Some organizations include strategy details in test plan itself (here is good example of this). Some organizations list strategy as a subsection in testing plan but details are separated out in different test strategy document. Project scope and test focus is defined in test plan. Basically, it deals with test coverage, features to be tested, features not to be tested, estimation, scheduling and resource management. Whereas test strategy defines guidelines for test approach to be followed in order to achieve the test objectives and execution of test types defined in testing plan. It deals with test objective, approach, test environment, automation strategy and tools, and risk analysis with contingency plan. To summarize test plan is a vision of what you want to achieve and test strategy is an action plan designed to achieve this vision Hope this will clear all your doubts. James Bach has more discussion on this topic here . Process to develop a good test strategy document: Don t just follow the templates without understanding what works best for your project. Every client has its own requirements and you must stick to the things that work perfectly for you. Do not copy any organization or any standard blindly. Always make sure if that is helping for you and your processes. Below is a sample strategy template that will outline what should be covered in this plan along with some examples to illustrate what make sense to cover under each component. Common sections of test strategy document: Step 1 Scope and Overview: Project overview along with information on who should use this document. Also include details like who will review and approve this document. Define testing activities and phases to be carried out with timelines with respect to overall project timelines defined in test plan. Step 2 Test Approach: Define testing process, level of testing, roles and responsibilities of every team member. For every test type defined in test plan (e. g. unit. integration, system, regression, installation/uninstallation. usability, load, performance, and security testing) describe why it should be conducted along with details like when to start, test owner, responsibilities, testing approach and details of automation strategy and tool if applicable. In test execution there are various activities like adding new defects, defect triage, defect assignments, re-testing, regression testing and finally test sign-off. You must define exact steps to be followed for each activity. You can follow same process which worked for you in your previous test cycles. A visio presentation of all these activities including number of testers and who will work on what activity is very helpful to quickly understand roles and responsibilities in the team. Por exemplo. defect management cycle mention the process to log new defect. Where to log it, how to log new defects, what should be the defect status, who should do defect triage, whom to assign defects after triage etc. Also define change management process. This includes defining change request submission, template to be used, and process to handle the request. Step 3 Test Environment: Test environment setup should outline information about number of environments and required setup for each environment. Por exemplo. one test environment for functional test team and another for UAT team. Define number of users supported on each environment, access roles for each user, software and hardware requirements like operating system, memory, free disk space, number of systems etc. Defining test data requirements is equally important. Provide clear instruction on how to create test data (either generate data or use production data by masking fields for privacy). Define test data backup and restore strategy. Test environment database may run into problems due to unhandled conditions in the code. I remember the problems we faced on one of the projects when there was no database backup strategy defined and we lost whole data due to code issues. Backup and restore process should define who will take backups, when to take backup, what to include in backup, when to restore database, who will restore it and data masking steps to be followed if database is restored. Step 4 Testing Tools: Define test management and automation tools required for test execution. For performance, load and security testing describe the test approach and tools required. Mention whether it is open source or commercial tool and how many users are supported on it and plan accordingly. Step 5 Release Control: As mentioned in our last UAT article. unplanned release cycle could result into different software versions on test and UAT environments. Release management plan with proper version history will ensure test execution of all modifications in that release. Por exemplo. set build management process which will answer where new build should made available, where it should be deployed, when to get new build, from where to get the production build, who will give go, no-go signal for production release etc. Step 6 Risk Analysis: List all risks that you envision. Provide a clear plan to mitigate these risks and also a contingency plan in case if you see these risks in reality. Step 7 Review and Approvals: When all these activities are defined in test strategy plan it needs to be reviewed for sign-off by all entities involved like project management, business team, development team and system administration (or environment management) team. Summary of review changes should be tracked at the begging of the document along with approver name, date and comment. Also it s a living document meaning this should be continuously reviewed and updated with the testing process enhancements. Conclusion: Test strategy is not a piece of paper. It s the reflection of whole QA activities in software testing life cycle. Refer this document time to time in test execution process and follow plan till the software release. When project nears the release date it s fairly easy cut on testing activities by ignoring what you have defined in test strategy document. But it is advisable to discuss with your team whether or not cutting down on any particular activity will help for release without any potential risk of major issues post release. Most of the agile teams cut down on writing strategy document as team focus is on test execution rather than documentation. But having a basic test strategy plan always help to clearly plan and mitigate risks involved in the project. Agile teams can capture and document all high level activities to complete test execution on time without any issues. I m sure developing a good test strategy plan and committing to follow it will definitely improve testing process and quality of the software. It would be my pleasure if this article inspires you to write a test strategy plan for your project If you like this post please consider sharing it with your friends
Comments
Post a Comment