Beruflich Dokumente
Kultur Dokumente
http://www.tenstep.com.br/site/index.jsp?pag=methodology&uid=88
Antes que você possa ser um bom 'gerente de projeto' e possa aplicar boas
técnicas de 'gerenciamento de projetos', você deve estar seguro de que o
trabalho que você está assumindo é, de fato, um projeto. Algumas pessoas
dizem que todo o trabalho é um projeto, mas não é exatamente isto. Há
realmente múltiplos tipos de trabalho – suporte (apoio), operações,
gerenciamento, projetos, etc.
Por outro lado, os projetos não são rotineiros. A maior diferença dessas
categorias do trabalho é que os projetos, por definição, têm uma data de início
e de término definidas. Existe um ponto de tempo no qual o trabalho não
existiu (antes do projeto), existe (o projeto), e não existe outra vez (após o
projeto). Esta é a chave para determinar se um trabalho é um projeto.
Entretanto, outras características de um projeto incluem:
• um Escopo definido,
• um orçamento finito,
• um resultado final específico (ou deliverables) e
• recursos designados.
Outra característica de um projeto é que o trabalho é único. Mesmo se um
projeto for semelhante a outro, ele não é exatamente o mesmo porque as
circunstâncias mudam, e porque as coisas são sempre diferentes quando você
está lidando com pessoas.
Dito isto, você deve conhecer a prática. Na teoria, os projetos podem ter uma
hora, 100 horas ou até 100.000 horas. Então, você deve reconhecer que,
embora a criação de um deliverable (resultado esperado) pequeno seja um
projeto, a mesma não necessita da estrutura e da disciplina de um projeto
maior. Um projeto de uma hora, você "somente executa". Toda a análise e o
projeto estão na sua cabeça. Para um projeto de vinte horas você, na maior
parte, 'simplesmente executa'. Entretanto, agora você poderá necessitar
planejar um pouco, comunicar-se um pouco, talvez tratar um pouco dos
problemas. Um projeto de cem horas resulta em demasiado trabalho de
planejamento e controle. Por exemplo, você necessita começar a definir o
trabalho e construir um workplan simples. Um projeto de 5.000 horas necessita
toda a disciplina do gerenciamento de projetos. No outro extremo, um projeto
de 100.000 horas provavelmente possui muitas coisas para colocarmos nossas
cabeças em torno dele. Este requer que você divida o projeto maior em projetos
menores, mas relacionados, para que todo o trabalho seja executado.
Todos os projetos devem dedicar no inicio um tempo para sua definição. Não
necessita muitas informações para definir um projeto pequeno e portanto esse
trabalho é bem curto. Mas, ao crescer os projetos chegam a ser maiores e
maiores, é muito importante à necessidade de entender completamente o que
se está solicitando, e mais difícil de definir um acordo sobre o que deve ser
entregue. Portanto, se requer mais tempo para planificar o trabalho e suas
tarefas.
Em termos gerais, quanto maior for um projeto, maior é o tempo tomado para
a definição do trabalho. Você necessita ter informações definidas, suficientes e
documentadas para conseguir um acordo com seu Sponsor sobre os objetivos,
deliverables, estimativa de custo, duração e escopo do projeto.
O processo de definição de um grande projeto é similar para um projeto médio.
A diferença é que no grande projeto tem mais informação necessária para
definir o projeto, e requer mais tempo para completar o processo de definição:
1. Busque todas as informações que podem ser aplicada para este projeto.
Este inclui qualquer deliverables (resultado esperado) do projeto, tais
como: memorandos, e-mail, etc. Em muitos casos, antes de começar o
projeto, o cliente deve realizar uma análise de custo / beneficio ou
estabelecer uma proposta sobre o valor do projeto, informações úteis para
a definição do projeto. Todas estas informações devem ser recopiladas
como ponto de partida para compreender e entender o trabalho que se
fará.
2. Trabalhe com seu Gerente, e o Patrocinador do Projeto (Sponsor) para
entender qual será o processo de aprovação mais adequado para a
definição do projeto. Por exemplo, determine se o Patrocinador do Projeto
(Sponsor) deverá aprovar a Definição do Projeto antes dos outros
envolvidos, ou deseja ter a última palavra na aprovação final. Também
determine quem realmente tem que aprovar o documento, assim como os
que devem receber só uma copia final.
3. Reúna-se com os Stakeholders (os envolvidos e os responsáveis)
apropriados (Gerentes, clientes, partes interessadas) e tente entender
suas opiniões sobre o trabalho do projeto solicitado. Antes da reunião
Certifique-se de que você está familiarizado com a informação básica para
definir um projeto deste tamanho. Se você não tem certeza de qual
informação coletar é um sinal de que você não está preparado para fazer
as perguntas necessárias. Você pode revisar o template de Definição do
Projeto para saber quais são as informações requeridas. Em geral, esta
informação inclui:
• Sumário Executivo (opcional). O documento de definição do
Projeto pode ser grande e difícil para a digestão dos executivos.
Você pode incluir um Sumário executivo para executivos. O Sumario
Executivo é uma revisão do documento de Definição do Projeto
atual, ele não é uma revisão do projeto.
• Visão Geral do Projeto. Descreva a finalidade do projeto e o
contexto do projeto a se realizar. Incluir os benefícios e metas de
negócio do projeto a contribuir.
• Objetivos do Projeto. Descreva os objetivos do projeto a ser
realizado. Os objetivos do projeto devem ter suporte das metas e
objetivos do negocio. Os deliverables produzidos devem ter suporte
dos objetivos do projeto. Para mais informações sobre metas e
objetivos, ver 1.2.1 Definir Tarefas / Técnicas / Metas e Objetivos.
• Escopo do Projeto. Defina os deliverables a serem criados e
forneça um comentário sobre as características dos deliverables.
Também inclua informações das descrições do que não será
produzido no projeto. Em outras palavras, O que está fora deste
escopo? O que o projeto poderá produzir, mas não será produzido,
isto é muito importante que seja descrito claramente. Assim será
muito mais fácil manejar mudanças do escopo. Para maiores
detalhes veja 5.1.1 Definindo o Escopo. Em adicionar dos
deliverables, você deve ter a descrição do escopo em termos mais
especifico, por exemplo:
• Os dados que serão usados e os dados que ficarão fora do
escopo
• As organizações (departamentos) afetadas e as não afetadas
• Os processo do negócio que estarão dentro do escopo e fora
do escopo
• Os transações do negócio que estarão dentro do escopo e fora
do escopo
• Descreva alguns outros projetos afetados
• Defina alguns outros itens dentro-do-escopo / fora-do-escopo
• Estimativa das horas do Esforço. Estimar o esforço
requerido para completar o projeto. Fornecer informações de como a
estimativa foi preparada, as suposições feitas, etc. Para maiores
informações, veja 2.1.1 Construa o Plano de Trabalho (Workplan) e
o Orçamento / Processo / Estimação.
• Estimativa da Duração. Estimar a duração do projeto para
finalizar. Se a data inicial é conhecida, a data final estimada poderá
ser definida. Para maiores informações, veja 2.1.1 Construa o Plano
de Trabalho (Workplan) e o Orçamento / Processo / Estimação.
• Estimativa dos Custos. Estimar o custo dos trabalhadores,
baseado nas horas de esforço. Adicione qualquer despesa que não
seja mão-de-obra como hardware, software, treinamento, viagem,
etc. Para maiores informações, veja 2.1.1 Construa o Plano de
Trabalho (Workplan) e o Orçamento / Processo / Estimação.
• Suposições Principais. Suposições são eventos externos que
devem ocorrer para que o projeto obtenha sucesso. Se parecer mais
que provável que esses eventos ocorram, então eles podem ser
listados como suposições. Suposições podem ser identificadas
através da experiência do conhecimento dos tipos de atividades ou
eventos que provavelmente ocorrerão na sua organização; sessões
de brainstorming com os clientes, stakeholders e membros da
equipe; e observando itens que serão identificados como de baixo
risco no processo de gerenciamento de riscos. Para maiores
informações, veja 7.1.3 Gerenciando Riscos / Processo / Suposições
e Riscos.
• Riscos Principais. Riscos são futuros eventos ou condições
externas que causarão problemas para o projeto se os mesmos
ocorrerem. Se existir uma boa probabilidade que algum desses
eventos venha a ocorrer, eles deverão ser identificados como riscos.
( A seção 7.1 Gerenciando Riscos / Processo fornece uma definição
de um risco com mais precisão) Para maiores informações, veja 7.1
Gerenciando Riscos / Processo.
• Abordagem. Descrever em geral as informações que
representam o workplan do Projeto. Essas informações são para o
beneficio do cliente e stakeholders que não podem interpretar
facilmente o atual workplan. Você deve descrever as principais fases
e milestones (marco miliário) do Projeto, e em geral a seqüência das
tarefas. Também comunicar quando os principais deliverables serão
produzidos e esclarecer algumas técnicas interessantes ou fora do
normal que serão utilizadas no projeto – por exemplo, Rapid
Application Development (RAD), joint Application design (JAD)
sessões etc. Dependendo do tamanho do seu Projeto, essa sessão
pode ser razoavelmente longa, mas não deve ultrapassar duas
paginas. Para outras idéias sobre como descrever a abordagem Veja
2.1.3 Construir o Plano de Trabalho (Workplan) e o Orçamento /
Processo / Abordagem.
• Organização do Projeto. A organização gráfica para grandes
projetos normalmente tem muitas caixas que refletem o
envolvimento de vários stakeholders. Por exemplo, o projeto pode
ter um Gerente de Projeto formal para representar a organização do
cliente e reporta para o Sponsor do projeto. O projeto pode ter um
Sponsor executivo e também um Sponsor do projeto para
representar o Sponsor executivo no dia a dia. Os stakeholders
principais podem formar um comitê de direção para fornecer uma
estratégia e orientação para o projeto. Vendedores e supridores
podem ter uma função formal e deve ser necessária uma
representação dentro da estrutura da organização. (As três
estruturas principais para organizar a equipe do projeto estão
descritas em 1.2.4 Definir Tarefas / Técnicas / Organização do
Projeto. Grandes Projetos também podem serem beneficiados diante
das definições como deliverables criados e aprovados. Ver mais
detalhes em 1.2.3 Definir Tarefas / Técnicas / Matriz de
Responsabilidades. Muitas dessas especificas funções do projeto se
descrevem em 1.2.2 Definir Tarefas / Técnicas / Funções e
Responsabilidades.
4. Elabore seu primeiro rascunho do documento Definição do Projeto.
Escreva o conteúdo considerando o leitor e não para o seu beneficio. Essa
informação deve ser clara e fácil para o entendimento do leitor.
5. Um rascunho do Plano de Trabalho (Workplan) deve iniciar-se, dando
toda informação que se tem disponível no momento. A informação do
workplan se utiliza como entrada no documento Definição do Projeto, e
a informação contida nesta definição se utiliza para ajudar a construir o
Plano de Trabalho (Workplan). Para mais informações ver 2.0
Construir Plano de Trabalho (Workplan) e o Orçamento.
6. Documente os Procedimentos no Gerenciamento de Projetos para
este projeto. É importante documentá-los no inicio e obter o compromisso
da gerência, clientes e de outros envolvidos e responsáveis
(Stakeholders). Por exemplo, é muito mais fácil resolver um pedido de
mudança de escopo mediante um procedimento previamente aprovado do
que “inventar” o procedimento e resolver a mudança de escopo ao mesmo
tempo. Quanto maior for o seu projeto, maiores são as necessidades de
formalidade e disciplina dos Procedimentos no Gerenciamento de Projetos.
Se você tem procedimentos definidos de outro projeto similar, ou se sua
organização tem procedimentos padrão definidos, utilize-os como ponto de
partida.
7. Circule a Definição do Projeto e os Procedimentos no
Gerenciamento de Projetos em forma de rascunho, a fim de arrecadar a
retro-alimentação (feedback) e começar a construir o consenso para sua
posterior aprovação. Os primeiros rascunhos podem enviar-se a um
reduzido grupo de pessoas interessadas. O Plano de trabalho
(Workplan) normalmente não requer ser circulado, a menos que alguém
o solicite em forma particular.
8. Atualize os documentos para incorporar as informações obtidas do
processo de retro-alimentação (feedback).
9. Circule os documentos revisados a um grupo maior de pessoas envolvidas
ou responsáveis para obter uma ronda adicional de retro-alimentação
(feedback). Atualize os documentos para incorporar as informações
obtidas do processo de retro-alimentação (feedback).
10. Iniciar o Processo de Aprovação. Este processo foi desenvolvido e
aprovado no passo № 2. Para obter maiores informações de como circular
o documento e as opções para obter a aprovação ver 1.2 Definir Tarefas /
Técnicas.
11. Após o término do processo de aprovação, circule cópias dos documentos
aprovados como Definição do Projeto e Procedimentos do
Gerenciamento de Projetos a todas as pessoas interessadas
(Stakeholders).
12. Executar o Trabalho. O Projeto agora está pronto para começar
oficialmente. Deverá seguir um típico ciclo de vida baseado nas
características do projeto. Para maiores detalhes, visite
www.LifecycleStep.com.
13. Gerenciar o Trabalho. Uma vez iniciado o trabalho, ele será gerenciado
através dos processos de gerenciamento do trabalho (gerenciar o escopo,
comunicação, risco, etc.). Estes processos de gerenciamento de projetos
devem ser utilizados de uma maneira escalavel, conforme as
necessidades. Procedimentos genéricos podem ser estabelecidos para
administrar todos os projetos de tamanhos grandes e riscos similares.
14. Após a implementação, o trabalho estará completo e o cliente
demonstrara sua aprovação e aceitação da solução formalmente por
escrito. O projeto então poderá ser concluído.
**Templates Associados**