TenStep Processo de Gerenciamento de Projetos

http://www.tenstep.com.br/site/index.jsp?pag=methodology&uid=88

1.0 Definir Tarefas

Visão Geral (1.0.P1)

Quantas vezes você escutou ou esteve envolvido em um projeto que falhou
terrivelmente? Ou que talvez não tenha sido tão bem sucedido quanto deveria?
Você alguma vez perdeu tempo olhando para trás para descobrir o que fez com
que o projeto falhasse? Se você o fez, possivelmente você disse, "Você sabe,
deveríamos gastar mais tempo planejando". A maioria dos projetos possui
prazos, e parece que eles estão se tornando cada vez mais curtos.
Cumprir com prazos curtos pressiona o gerente de projetos a iniciar o projeto o
mais rapidamente possível. Contudo, antes do início do trabalho do projeto, é
necessário haver um tempo de planejamento anterior para garantir que:
1. o trabalho está adequadamente compreendido, e
2. há uma concordância sobre ele.
Isto não é perda de tempo ou 'overhead'. Este é o tempo que o gerente de
projeto gasta para garantir que a equipe de projeto e o cliente tenham a
mesma idéia sobre o que o projeto irá oferecer, quando o mesmo será
concluído, quanto custará, quem fará o trabalho e como o mesmo será
realizado.
Ao final de um projeto difícil, os benefícios do planejamento serão óbvios. Mas,
os benefícios também são conhecidos antecipadamente. Em um nível alto, os
benefícios incluem:
• Entender e concordar a respeito dos objetivos, deliverables, Escopo, risco,
custos, abordagem do projeto, etc. (Definição do Projeto).
• Determinar se o caso original do negócio ainda é válido. Por exemplo, um
projeto que exige 10.000 horas de trabalho pode fazer sentido. Se o
processo de planejamento mais detalhado resultar em uma estimativa
mais refinada de 20.000 horas, o projeto pode não fazer mais sentido.
• Certificar-se de que os recursos que necessários estarão disponíveis
quando você necessitar deles.
• Uma linha de partida de alto-nível, a partir da qual o progresso possa ser
comparado.
• Validar os processos utilizados no projeto antecipadamente com o cliente.
Deveria fazer sentido que projetos pequenos necessitassem de um ciclo mais
curto de planejamento, e que projetos maiores necessitassem de um ciclo de
planejamento mais longo. O esforço necessário para planejar o projeto depende
da quantidade de informações, e do nível de detalhes que deve ser entendido e
documentado. A duração necessária para definir o trabalho depende do período
de tempo necessário para descobrir e documentar a informação, bem como o
tempo necessário para obter à concordância e a aprovação do cliente. Algumas
vezes, o gerente do projeto pode se frustrar por causa das dificuldades para
obtenção da concordância do cliente sobre o Escopo, o transcurso de tempo e
os custos. Mas, esta é exatamente a razão porque este trabalho é feito antes.
Pense nos problemas que você encontrará tentando obter a concordância do
cliente sobre o Escopo, cronograma ou custos quando o trabalho tiver iniciado e
os deliverables estiverem sendo realmente produzidos.
Antes do início do ciclo de vida do projeto (analises, design, construção, etc.),
uma série de itens deve ser definido no processo de planejamento. Em projetos
menores, muitas destas condições são atendidas de maneira informal ou
implícita. Contudo, quanto maior for um projeto, mais importante é fazer com
que estes critérios sejam formalmente e explicitamente atendidos.
• O cliente aprova o início do planejamento. Normalmente, a aprovação
implícita é presumida de haver ocorrido até para fazer com que o projeto
seja iniciado. Contudo, se o projeto não tiver um caso de negócios
preparado e se não passar por um processo de priorização, a aprovação
explícita deverá ser obtida antes do início do planejamento do projeto.
• O Projeto está definido. Isto é, documentado na Definição do Projeto,
que contém objetivos, Escopo, hipóteses, deliverables, orçamento, etc.
(Para projetos médios ou pequenos, isto pode ser a Definição Resumida do
Projeto ou uma Solicitação de Serviço).
• O Workplan do Projeto é criado. Um workplan deve ser preparado e
utilizado para gerenciar o esforço. Isto inclui pontos de verificação ou
marcos miliários, sempre que o projeto puder ser avaliado para assegurar
a sua continuidade.
• O Cliente aprova o início do projeto. Isto significa uma Definição de
Projeto assinada e aprovada. O patrocinador deve assinar o documento
para garantir a concordância.
• Os Procedimentos de Gerenciamento do Projeto são definidos e
aprovados – Os Procedimentos devem estar definidos para que se possa
descrever como o projeto gerenciará Incidências, comunicação, riscos,
qualidade, Escopo, etc. Isto é especialmente verdadeiro para grandes
projetos, e menos importante quando um projeto se torna menor.
• Os recursos da equipe do projeto são designados – Você deve ter as
pessoas certas para contratar e para executar o projeto. Algumas vezes,
projetos válidos, aprovados necessitam ser atrasados porque as pessoas
com as habilidades necessárias não estão disponíveis.
Antes de você entender como definir um projeto, você deve ter um claro
entendimento do que é uma definição de projeto. Isto se tornará mais claro
quando as técnicas de gerenciamento de um projeto forem apropriadas. Para
uma visão geral, veja 1.0.1 O que é um Projeto? Quando você tiver uma idéia
do que é um projeto, você também poderá confirmar seu entendimento na
função de um gerente de projeto em 1.0.2 A Função do Gerente de Projeto.
Agora, podemos prosseguir com o TenStep Processo de Gerenciamento de
Projetos®.

1.0.1 O que é um Projeto?

Visão Geral (1.0.1.P1)

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.

O trabalho de suporte inclui manutenção sistemas, soluções ou processos que

são atuais. Para pessoas de desenvolvimento de TI, o trabalho de suporte
consiste em responder a perguntas, ir às reuniões regularmente agendadas,
solucionar os problemas nos sistemas de produção, etc. Para o pessoal de
vendas, isto pode significar fazer chamadas diárias de vendas, movimentar
contratos através de um processo de aprovação, atualizar registros de
chamadas, etc. Trabalho de operações consiste no trabalho de rotina requerido
para execução dos processos de negocio da empresa. Para um encarregado de
contas a receber, isto poderá significar verificação de contratos, de contas de
saldos, afixar notícias de jornal, fechar o sistema, etc. O trabalho de
gerenciamento é requerido para gerenciar e liderar pessoas e processos do
negocio.

Os critérios-chave são de que este tipo de trabalho é continuo e é uma parte

rotineira de seu trabalho. Este é o trabalho que você faz hoje, fará amanhã, e
daqui a um mês.

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.

1.0.2 A Função do Gerente de Projetos

Visão Geral (1.0.2.P1)

Um funcionário novo na sala de correspondência da empresa observou um
homem mais velho sentado a um canto, classificando as
correspondências, pesando pacotes, colocando selos e
fazendo outros trabalhos simples. Perguntou a seu
supervisor quem era o homem.
"Aquele é José." disse o supervisor. "Ela trabalha para a
empresa há 35 anos e está próximo da aposentadoria".
"Verdade?", respondeu o funcionário. "E ele sempre esteve
na sala de correspondência?"
"Não, ele saiu há alguns anos atrás. Mas pediu transferência para cá
novamente - após ter trabalhado durante vários anos como gerente de
projeto."

Superficialmente, a função de um gerente de projeto deveria ser fácil de

descrever. Na verdade, sob a perspectiva de um livro texto provavelmente o
é. Mas o desafio de entender as funções e responsabilidades de gerenciamento
de projetos é diferente de empresa para empresa. Assim, embora o processo
de TenStep forneça uma perspectiva geral desta função, você ainda deverá
determinar qual é a função de um gerente de projeto em sua empresa ou em
sua organização.

Definição Geral (1.0.2.P2)

Em geral, o gerente de projeto é responsável pelo sucesso total do projeto.
Em algumas empresas, esta pessoa pode ser chamada de Coordenador de
Projeto, ou Líder de Equipe. Contudo, o aspecto chave é que a pessoa é
responsável pelo sucesso do projeto.
O que transforma um projeto em um sucesso? Se você seguir o TenStep
Processo de Gerenciamento de Projetos®, ou uma abordagem
semelhante, você primeiramente deverá definir o projeto e construir o
workplan. É aí que as responsabilidades do gerente de projeto iniciam. Se o
projeto iniciar e, mais tarde, você descobrir que não estava certo sobre o seu
Escopo, o gerente de projeto é quem será responsabilizado. Se o seu projeto
estiver executando um workplan pobre, o gerente de projeto é responsável.
O trabalho de definição do projeto significa que você entendeu e recebeu a
total concordância sobre os objetivos, Escopo, risco, abordagem, orçamento,
etc. Isto também inclui definir ou adotar os procedimentos específicos de
gerenciamento do projeto que serão utilizados para gerenciar o projeto.
Isto não significa que o gerente de projeto necessite fazer todo este trabalho
sozinho. Pode haver uma equipe inteira auxiliando na criação da Definição do
Projeto e no workplan. Contudo, se algo não andar direito, o gerente de
projeto é responsável.
Responsabilidades pelo Processo (1.0.2.P3)
Uma vez iniciado o projeto, o gerente de projeto deve gerenciar e controlar o
trabalho, incluindo:
• Identificar, rastrear o gerenciamento e resolver Incidências do projeto.
 • Disseminar pro-ativamente as informações do projeto a todas as partes
interessadas.
• Identificar, gerenciar e atenuar os riscos do projeto.
• Assegurar uma solução com uma qualidade aceitável.Gerenciar pró
ativamente o Escopo para garantir que somente o que foi acordado seja
entregue, a menos que as mudanças sejam aprovadas através do
gerenciamento do Escopo.
• Definir e coletar métricas para dar uma idéia de como o projeto está
progredindo e se os deliverables produzidos são aceitáveis.
• Controlar o workplan total para assegurar que o trabalho seja designado e
concluído dentro do prazo e do orçamento.
Novamente, isto não significa que o gerente de projeto faça tudo isto
fisicamente, mas ele deve certificar-se de que isto realmente está ocorrendo.
Se o projeto tiver problemas, ou seu Escopo avançar lentamente, ou enfrentar
riscos, ou não estiver estabelecendo as expectativas corretamente, o gerente
de projeto será a pessoa responsável por isto.
Para gerenciar os processos de gerenciamento de um projeto, uma pessoa
deve:
• ser bem organizado,
• possuir uma grande capacidade de acompanhamento,
• ser orientada ao processo,
• ser capaz de desempenhar múltiplas tarefas,
• ter um processo de raciocínio lógico,
• ser capaz de determinar as causas principais,
• ter uma boa capacidade de análise,
• ser um bom avaliador e gerente do orçamento, e
• ter autodisciplina.

Responsabilidades das Pessoas (1.0.2.P4)

Além das habilidades para o processo, um gerente de projeto deve ter uma
boa capacidade de gerenciamento de pessoal. Isto inclui:
• Ter disciplina e capacidade de gerenciamento geral, para certificar-se de
que as pessoas seguem os processos e procedimentos padrão.
 • Estabelecer habilidades de liderança para fazer com que a equipe siga as
suas instruções. Liderança significa comunicar uma visão e fazer com que
a equipe a aceita e lute para chegar lá com você.
• Estabelecer expectativas razoáveis, desafiadoras e claras para as pessoas,
e fazer com que elas se sintam responsáveis pelo atendimento das
expectativas. Isto inclui fornecer um bom feedback sobre o desempenho
aos integrantes da equipe.
• Habilidades para criação de uma equipe, de modo a que as pessoas
trabalhem bem em conjunto, e se sintam motivadas para trabalharem
duramente pela causa do projeto e pelos outros integrantes da equipe.
Quanto maior for sua equipe, e mais longo o projeto, mais importante é
ter boas habilidades para criar uma equipe.
• Habilidades pró-ativas verbais e escritas de comunicador, incluindo boas e
ativas habilidades de escutar.
Novamente, você é responsável pelo sucesso do projeto. Se a equipe tiver
uma baixa moral e estiver perdendo prazos, você deverá tentar resolver isto.
Se os membros da equipe não entendem exatamente o que necessitam fazer
e quando devem fazê-lo, você será o responsável por isto.

Múltiplas Funções (1.0.2.P5)

Dependendo do tamanho e da complexidade do projeto, o gerente de projeto
poderá assumir outras responsabilidades além do gerenciamento do trabalho.
Por exemplo, o gerente de projeto pode auxiliar com a coleta das
necessidades do negócio, ou ele poderá auxiliar no projeto de um sistema de
gerenciamento de banco de dados, ou redigir a documentação do projeto. O
gerenciamento do projeto é uma função especial que uma pessoa deve
preencher, mesmo se a pessoa também estiver trabalhando em outras
funções.
Por exemplo, um gerente de projeto pode gerenciar o projeto durante 45% de
seu tempo, executar a análise do negócio por 25%, trabalhar no design por
15% e escrever a documentação durante 15% do tempo. Isto não significa
que uma das responsabilidades de uma função de gerente de projeto seja
gastar 15% de seu tempo no projeto. Ao invés disso, apenas significa que o
projeto não é grande o bastante para necessitar de um gerente de projeto em
tempo integral. O gerente de projeto gasta o resto de seu tempo em outras
funções do projeto tais como Analista de Negócios, Projetista e Redator
Técnico. Dependendo do tamanho de seus projetos, e da maneira como a sua
empresa é organizada, o tempo de um gerente de projeto pode ser alocado
segundo uma dessas três formas:
 • Pode ter uma função com tempo integral em um projeto grande.
• Pode ter responsabilidades de gerenciamento de projeto para múltiplos
projetos, ocupando cada um deles tempo inferior ao tempo integral, mas
sua combinação preenche uma função com tempo integral.
• Pode preencher múltiplas funções, sendo exigido para cada um deles um
determinado nível de habilidade e de responsabilidade. Em um projeto,
por exemplo, pode ser, ao mesmo tempo, um gerente de projeto e um
analista.

Responsabilidades em uma organização de matriz (1.0.2.P6)

Atualmente, a estrutura organizacional que mais predomina é alguma forma
da estrutura de matriz (ver 1.2.4 Organização do Projeto ). A organização de
matriz permite a utilização mais eficiente dos recursos humanos em uma
empresa. Entretanto, um dos desafios da organização de matriz é que os
membros da equipe estão designados para um projeto para trabalharem (em
tempo integral ou meio turno), mas os recursos se reportam a alguma outra
pessoa dos recursos humanos. Isto pode significar que é mais difícil conseguir
que os recursos façam as coisas que você necessita e, às vezes, há uma
sensação de que os membros da equipe prefeririam atender às solicitações de
seus gerentes funcionais, ao invés daquilo que o gerente de projeto necessita.
Neste tipo de estrutura, há ainda um número de coisas pró-ativas que você
pode fazer.
• Embora a equipe não se reporte funcionalmente ao gerente de projeto,
seu trabalho no projeto deveria ser uma contribuição para a avaliação
total do desempenho. Assim, você pode tentar fazer as pessoas
responsabilizarem-se, certificando-se de que elas entendem que você
estará fornecendo feedback sobre a avaliação de sue desempenho. Isto
também deve ser reiterado e acordado pelos gerentes de função. Se as
pessoas não estiverem cumprindo seus prazos finais, então talvez se faça
necessária uma combinação de seu feedback, bem como um feedback do
gerente funcional.
• Há técnicas e processos de gerenciamento de projeto que devem ser
utilizados. Primeiramente, se a disponibilidade e o desempenho da equipe
forem duvidosos, você deve apontar isto como sendo um risco para o
projeto. Como parte do gerenciamento de risco, você necessita colocar
um plano pró-ativo em ação, para certificar-se de que este risco está
sendo administrado.
• Quando o pessoal falho em relação aos prazos finais, você pode precisar
levantar uma questão e executar o gerenciamento de Incidências.
 Durante o gerenciamento de Incidências, você procura outra vez pela
causa do problema. Por exemplo, eles estão perdendo os prazos finais
porque estão sendo retirados de seu projeto para fazer outro trabalho, tal
como o suporte da aplicação. Se isto estiver ocorrendo, isto pode
necessitar ser tratado de alguma maneira. Eles podiam perdendo os
prazos porque as estimativas iniciais eram demasiado baixas. Se for
assim, isso precisa ser resolvido de uma outra maneira. Eles podiam
perdendo os prazos por causa de problemas de desempenho. Outra vez,
isso precisa ser resolvido de uma terceira maneira, com a ajuda dos
gerentes funcionais.
• Certifique-se de que os membros de sua equipe estão se comunicando
pro-ativamente com você. Em muitos casos, não é o fato de que as
pessoas perdem seus prazos finais que deixam o gerente de projeto
frustrado. É que eles nem sempre o avisam. Por exemplo, Se um
membro da equipe tiver um deliverable para o fim da semana, mas se
envolve durante três dias na solução de um problema da produção, ele
precisa informá-lo, de modo que você possa tomar qualquer providência
apropriada. Se eles apenas perdem seus prazos finais, mas não lhe dizem
a razão e nem o avisam com antecedência, então eles não estão
gerenciando as expectativas como deveriam. De igual forma, você deve
comunicar-se pro-ativamente também, e certificar-se de que a equipe
entende as datas de vencimento e as expectativas. O gerente de projeto
também deve comunicar-se pró ativamente com os gerentes funcionais e
certificar-se de que eles saibam quando houver Incidências de
compartilhamento de recursos ou Incidências de desempenho do pessoal.
O gerenciamento de matriz envolve um equilíbrio complexo e delicado entre
gerentes de projeto e gerentes funcionais de pessoal. Ao mesmo tempo em
que você se esforça para obter seus resultados com pessoas que talvez nem
trabalhem para você em tempo integral, você também pode ter um não
projeto adicional e responsabilidades funcionais. O gerente de projeto sempre
limitou a autoridade de gerenciamento de pessoal nestas situações. E, ainda é
possível terminar com sucesso seus projetos. Há muitos processos e técnicas
de gerenciamento de projeto que podem ajudar. Você deve também se
certificar de utilizar o patrocinador do projeto. Apesar de tudo, é o projeto
deles. Eles podem lhe ajudar a gerar a urgência e o foco, e também influenciar
os gerentes funcionais, se necessário, para garantir que as pessoas estão
disponíveis quando for necessário para o projeto ser bem sucedido.
Obrigando-se com o Gerenciamento do Projeto, mas não se
Responsabilizando (1.0.2.P7)
Em algumas organizações, o gerente de projeto é o responsável pelo sucesso
do projeto, mas não possui o nível correto de responsabilidade. Gerenciar a
equipe em uma organização de matriz é um exemplo disso. Você é solicitado a
gerenciar um projeto utilizando pessoal que você não gerencia diretamente.
Em outros casos, você pode descobrir que sua habilidade para resolver
Incidências é prejudicada porque você não esta em uma posição
suficientemente alta na organização e você necessita confiar em um gerente
que tem um nível mais alto na organização para ajudar-te. Em outros
exemplos, você pode descobrir que sua capacidade de inovação e flexibilidade
é restringida pela inércia e pelas políticas organizacionais.
Todas estas situações podem causar frustrações. Uma forma de lidar com isso
é definir funções e responsabilidades como parte da Definição do Projeto. Isto
pode ajudar a ajustar e gerenciar expectativas. Por exemplo, se você não tiver
nenhuma autoridade com relação à aprovação do orçamento ou da despesa,
então observe isso antes, juntamente com um processo para aprovação da
despesa. Desta maneira, se os problemas surgirem depois, todos saberão
quem tem o nível correto de autoridade para os resolver. Para a maioria dos
gerentes de projeto, o nível da frustração não é causado tanto pela falta de
poder como pela ambigüidade. Se o gerente de projeto não tiver autoridade, é
importante saber quem a tem, e que processo é necessário para entrar em
ação.

1.1 Definir Tarefas / Processo

Visão Geral (1.1.P1)

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.

As seguintes páginas apresentam os processos recomendados para definir o

trabalho e as tarefas , dependendo do tamanho do projeto.
1.1.1 Definir Tarefas / Processo / Projetos Pequenos

Visão Geral (1.1.1.P1)

A etapa de definição de projetos pequenos cobre muitos tipos de trabalhos.
Em muitas empresas, projetos pequenos não são vistos ou gerenciados como
projetos. Muitas empresas chamam estes trabalhos de “melhoramentos” ou
requisições de trabalhos extras. Para a TenStep Processo de
Gerenciamento de Projetos®, estes trabalhos são considerados um projeto,
porque estes se enquadram nos critérios de uma definição de projeto. Este
trabalho é único, têm datas de começo, datas de término, resultados
esperados (deliverables), e etc. Uma questão importante para projetos
pequenos é que os trabalhos a serem realizados também são pequenos.
Em algumas empresas, pequenos números de horas trabalhadas ou de
empenho são considerados trabalhos de suporte ou operação. É difícil decidir
que um trabalho pequeno deveria ser gerenciado como suporte de uma
requisição de serviço ou gerenciado como um projeto pequeno. A distinção
usada pela TenStep é quando existe uma certa discrição de quando o trabalho
é completado. Se um problema ocorrer que requere uma solução rápida, então
esta é uma função de suporte da empresa. O trabalho é considerado de
suporte porque este é reativo e relacionado diretamente a um problema de
produção. Entretanto, se um problema aparece e pode ser priorizado e
realizado no futuro, então este já é considerado um projeto pequeno.
No geral, projetos pequenos podem ser classificados pelas seguintes
características:
• Horas exatas de empenho que são claramente projetos, mas tem curta
duração e um número pequenos de horas de empenho.
• Melhoramentos em processos existentes de produção e sistemas.
• Bugs e erros nos processos de produção que são problemáticos, mas
podem ser agendados para serem solucionados no futuro.
• Pequenos melhoramentos de processo.
• Descubra trabalhos que irão eventualmente virar Requisições de Serviço
ou até mesmo projetos.
• Mudanças em processos de produção que são o resultado de
requerimentos legais, de impostos, ou requerimentos de auditoria. Estes
requerimentos podem não serem considerados melhoramentos, pois
estes não fornecessem nenhum valor adicional ao negócio, mas ainda são
considerados projetos pequenos.
Se o trabalho é classificado como um projeto pequeno e discreto, isto não tira
seu aspecto crítico, ou o valor do requerimento. Isto apenas quer dizer que
existe discrição de quando este trabalho é completado. Por exemplo, se um
requerimento de serviço é importante o suficiente, então este terá a prioridade
de começar o mais cedo possível. Entretanto, uma requisição atrasada e
urgente poderia colocar outras requisições na espera para que esta seja
começada o quanto antes. A natureza de trabalhos discretos é que estes
podem sofrer decisões de priorização de trabalhos e suas datas de começo.
Isto fica em contraste com os trabalhos de suporte. Se um processo de
produção parou, ou está produzindo produtos com defeito, então estes
problemas precisão ser resolvidos na hora, e estes não podem ser
interrompidos por um requerimento de um projeto discreto e pequeno.
No geral, todo o trabalho discreto pode ser documentado, avaliado e
priorizado através de um processo de requisição de serviço. (projetos
pequenos).

O Processo de Requisição de Serviço (1.1.1.P2)

Geralmente, em um projeto pequeno, o esforço associado formalmente para
definir o trabalho e as tarefas é mínimo. O resultado dessa curta definição é
um documento de uma ou duas páginas, chamado, requisição de serviço.
O processo de definição de projeto pequeno é bem curto e mínimo, porém, o
processo para designar os trabalhos é diferente. Quando as definições dos
trabalhos para um projeto grande são completadas, os trabalhos estão prontos
para serem iniciados. Entretanto, para projetos menores pode haver várias
requisições de serviços que podem ser feitas a qualquer momento. O ideal é
que um processo seja estabelecido de modo que se colete as requisições de
serviços e designe-as aos membros do seu time baseando-se nas prioridades
dos clientes. Se já sabemos que haverá muitas requisições de serviços, é
importante nesta hora, criar um mecanismo para poder gerenciá-las, tendo
certeza que as requisições com prioridade alta já estão sendo trabalhadas. Os
processos mostrados abaixo podem ser utilizados para gerenciar as
requisições de serviço.
1. Quando o cliente submete a requisição. Se necessário, o cliente, com
a ajuda do Gerente de Projetos, completam o documento de requisição
de serviço. Mesmo que o trabalho seja pequeno, a requisição de serviço
formaliza os trabalhos que precisam ser feitos contendo as aprovações do
cliente. Uma requisição de serviço normalmente contém o trabalho que é
requerido, a prioridade do mesmo e o valor desta atividade para o
negócio do cliente.
2. O Gerente de Projetos revisa e esclarece. O Gerente de Projetos
revisa a requisição de serviço dando certeza que o trabalho em questão é
entendido. O Gerente de Projetos faz perguntas sobre o cliente, se
necessário, com a intenção de clarificar o que está sendo requerido. O
Gerente de Projetos também precisa entender a parte crítica da
requisição e quando qualquer trabalho pré-requisito precisa ser
completado primeiro.
3. Uma estimativa de alto nível é preparada.
• Se o Gerente de Projetos entende o trabalho a ser feito e possui o nível
técnico apropriado, deve fornecer uma estimativa de alto nível para as
horas de esforço e duração, que são informações que devem constar na
requisição de serviço. É possível, quando o cliente olhe para estas
estimativas, mude de idéia com relação à prioridade de cada trabalho. Por
exemplo, se o esforço estimado é muito maior do que o realizado, então a
prioridade pode ser rebaixada ou nivelada.
• Se o Gerente de Projeto não puder estimar o trabalho, este então,
designa para um membro do time, a criação destas estimativas. Se
ninguém do time tiver tempo e a expertise de criar estimativas de nível
alto, então o processo de estimativa precisar ser posto em um backlog. O
cliente tem que decidir se o esforço requerido para a coleta de informação
para criação de estimativas é de alta prioridade, então um membro do
time é designado para trabalhar somente nesta atividade e não em outras
requisições de serviços. Esta estimativa em alto nível é para priorização
somente. Quando o trabalho é designado, maiores detalhes sobre as
estimativas podem ser preparados, se necessário.
4. A requisição é designada ou arquivada. O gerente de projetos,
juntamente com o cliente, avaliam a requisição versus os trabalhos que
já estão designados e os que estão arquivados no backlog. Avalia-se
também a capacidade e as habilidades disponíveis no time para
determinar se o trabalho pode ser iniciado imediatamente. Se os recursos
necessários não estão disponíveis, ou se o trabalho tem prioridade baixa
em relação às outras requisições de serviços, então esta nova requisição
é arquivada no backlog. O backlog contém todos os trabalhos que foram
requeridos, estimados e priorizados, mas não está designado a iniciar
ainda.
5. Periodicamente Revise o Backlog. O Gerente de Projetos e o cliente
revisam o backlog periodicamente (semanal, quinzenal ou mensal).
Durante esta revisão, as requisições do backlog devem ser re-priorizadas
baseadas nas requisições de serviços novos, nas requisições de serviços
concluídos e na realidade atual. Quando a prioridade da requisição de
serviço for alta o suficiente e os recursos forem disponíveis, então o
 trabalho poderá ser iniciado. Se a requisição de serviço do backlog for
mais crítica do que o trabalho que está em progresso, então o trabalho
previamente designado fica em espera, volta ao backlog, ou é usado
como filtro enquanto a nova requisição é iniciada.
6. Revalide a Informação Inicial. Quando o trabalho é designado, a
pessoa responsável pelo trabalho deverá validar que a informação na
requisição de serviço é correta. Se as estimativas não estiverem corretas,
as novas informações devem ser documentadas e discutidas
imediatamente para ver se estas terão um impacto na prioridade. Por
exemplo, o cliente pode querer continuar com um projeto pequeno de
quarenta horas. Entretanto, se com maiores detalhes o projeto chega
perto de oitenta horas, então este pode não ser realizado naquele
momento. Podem existir outras requisições que são mais críticas e levam
menos tempo para serem completadas.
7. Execute o Trabalho. Se o trabalho continua sendo aprovado mesmo
após a validação das estimativas, então a execução do trabalho é
iniciada. Isto pode seguir um típico processo de ciclo de vida para
projetos pequenos. Visite www.lifecyclestep.com para mais informações.
8. Gerencie os Trabalhos. Uma vez iniciado o trabalho, este deve ser
gerenciado através do processo de Gerenciamento dos Trabalhos
(gerenciamento do escopo, da comunicação, dos riscos, etc.). Já que a
requisição é de um projeto pequeno, todos estes processos somente
serão utilizados quando for necessário. Os procedimentos de
gerenciamento de projetos não estão estabelecidos para projetos
pequenos e individuais, porém, procedimentos genéricos serão
estabelecidos para gerenciar todo o trabalho realizado através de
requisições de serviços. Este inclui procedimentos para manter o
progresso das requisições de serviços, gerenciar o escopo, a
comunicação, etc. Estes procedimentos de gerenciamento de projetos
normalmente não são executados especificamente para cada requisição
de serviço, mas sim de maneira geral para todos as requisições de
serviços.
9. Encerre os Trabalhos. Quando os trabalhos são completados, os
clientes devem indicar a aprovação dos mesmos. A requisição de serviço
deve ser fechada e encaminhada a um banco de dados onde é
armazenada para ser reutilizada quando preciso, como histórico. As
novas e modificadas deliverables podem ser direcionadas à produção.
Este direcionamento pode acontecer imediatamente, dentro de um
cronograma, ou parte de um novo lançamento. Em algumas organizações
a requisição de serviço não é fechada até o cliente assinar novamente,
significando que as deliverables estão dentro da produção esperada.
1.1.2 Definir Tarefas / Processo / Projetos Médios

Visão Geral (1.1.2.P1)

Considerando a diferença de opinião em como classificar pequenos projetos,
não deverá haver controvérsia em trabalhos de esforço médio – o trabalho
deverá ser definido definitivamente e gerenciado como um projeto. Você
precisa tentar manter a filosofia básica de escalabilidade (scalability) do
processo. Portanto, embora o trabalho seja definido como um projeto, a
definição do processo não é tão abrangente como em projetos grandes.
O projeto precisa ser definido claramente, mas a deliverable resultante não
precisa ser tão longa e/ou detalhada como uma definição formal de projeto.
Para um projeto de tamanho médio, utiliza-se uma Definição Abreviada do
Projeto. Geralmente é aceitável que esta informação se obtenha diretamente,
“descobrindo” a informação necessária, por exemplo:
1. Busque toda a informação que puder ser aplicada para este projeto. Isto
inclui qualquer deliverables (resultado
esperado) prévio do projeto, tais como:
memorandos, e-mails, etc. Em muitos casos,
antes de começar o projeto, o cliente deve
realizar uma análise (de alto - nível) do custo /
beneficio ou estabelecer uma proposta sobre o
valor do projeto, embora, estes podem não ser
obrigatório para os projetos médios. Toda esta
informação deve ser coletada como ponto de
partida para compreender e entender o trabalho
que será feito.
2. Trabalhe com seu Gerente, com os Stakeholders e o Patrocinador do
Projeto (Sponsor) para entender qual será o processo de aprovação mais
adequado. Por exemplo, o Patrocinador do Projeto (Sponsor) deverá
aprovar a Definição do Projeto antes dos outros envolvidos? , ou
melhor, deseja ter a última palavra na aprovação final? Determine quem
realmente tem que aprovar o documento, assim como o que devem
receber só uma copia final.
3. Reúna-se com os envolvidos e responsáveis apropriados (Gerentes,
clientes, partes interessadas) e tente entender suas opiniões sobre o
trabalho do projeto solicitado. Certifique-se de que você está
familiarizado com a informação que se requer para elaborar uma
Definição Abreviada do Projeto, de modo que você possa obter uma
compreensão profunda do máximo de informações possíveis.
 • Visão Geral do Projeto. Descreve o histórico e o contexto do
projeto a se realizar.
• Escopo do Projeto. Define claramente as fronteiras lógicas de
seu projeto, ou seja, define o que está dentro das fronteiras do
projeto e o que está fora desta fronteira. Para maiores detalhes
veja 5.1.1 Definindo o Escopo. Escopo pode ser definido de
várias maneiras, mas o foco para projetos médios deve estar
nas deliverables.
• Estimativas do Projeto - Esforço. Estima o esforço
requerido. Fornece 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 / Processo / Avalie.
• Estimativas do Projeto - Duração. Uma vez conhecidas às
horas de esforço, você poderá estimar o período de duração
para completar o projeto. 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 / Processo / Avalie.
• Estimativas do Projeto - Custos. Estima o custo do trabalho,
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 / Processo / Avalie.
• Suposições. 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 de conhecer os tipos de atividades ou
eventos que provavelmente ocorrerão na sua organização;
sessões de brainstorming com os clientes, stakeholders e
membros do time: e olhando itens que serão identificados
como de baixo risco no processo de gerenciamento de riscos.
Para maiores informações, veja 7.1.3 Gerencie
Riscos/Suposições e Riscos
• Riscos. Riscos são eventos externos futuros que poderão
causar problemas para o projeto se ocorrerem. Se existir uma
boa probabilidade que algum desses eventos venha a ocorrer,
eles poderão ser identificados como riscos. Para maiores
informações, veja 7.1 Gerencie Riscos/Processo
4. Elabore seu primeiro rascunho da Definição Abreviada do Projeto.
Escreva o conteúdo considerando o leitor e não para o Gerente do
 Projeto. Em outras palavras, escreva em termos compreensivos para o
cliente e não para os especialistas.
5. Um rascunho do Plano de Trabalho (Workplan) deve iniciar-se, dando
toda informação que se tem disponível nesse momento. A informação do
plano se utiliza como entrada na Definição Abreviada do Projeto, e a
informação contida nesta definição se utiliza para ajudar a construir o
Plano de Projeto.
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.
Por exemplo, é muito mais fácil resolver um pedido de troca de escopo
mediante um procedimento previamente aprovado que “inventar” o
procedimento e resolver a troca de escopo ao mesmo tempo.
7. Circule a Definição Abreviada 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. Opcional: Circule os documentos revisados a um grupo maior de pessoas
envolvidas ou responsáveis para obter uma ronda adicional de retro-
alimentação (feedback). Imediatamente, ponha em dia os documentos
com as respostas obtidas.
10. Inicie o processo de aprovação, segundo o que temos definido nos
pontos anteriores. (Ver a Seção de Técnicas para obter informações de
como circular o documento e as opções para obter aprovação)
11. Ao terminar o processo de aprovação, circule cópias dos documentos
aprovados como Definição Abreviada de Projeto e Procedimentos
no Gerenciamento de Projetos a todas as pessoas interessadas.
12. 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, veja www.lifecyclestep.com.
13. Gerenciando o trabalho. Uma vez iniciado o trabalho, ele será
gerenciado através do processo de gerenciamento do trabalho (gerenciar
escopo, comunicação, risco, etc.). Desde que o trabalho seja de tamanho
médio, estes processos de gerenciamento de projetos precisam ser
 colocados como necessários. Procedimentos genéricos podem ser
estabelecidos para administrar todos os projetos de tamanhos e riscos
similares.
14. Fechando o trabalho. Após a implementação, o trabalho estará
completo e o cliente manifestará sua aprovação e aceite da solução
formalmente por escrito. O projeto então poderá ser concluído.

1.1.3 Definir Tarefas / Processo / Projetos Grandes

Visão Geral (1.1.3.P1)

Os Grandes Projetos necessitam de tempo para definir o trabalho em nível de
detalhes requerido para começar o projeto. Se você não definir adequadamente
um pequeno ou médio projeto, a probabilidade das conseqüências não será
drástica. Ainda assim seu projeto é estimado para 500 horas de esforço mas
consume o dobro, este ainda não será uma catástrofe para sua empresa.
Entretanto, você não terá a mesma luxuria nos projetos grandes. Por exemplo,
se a estimativa do trabalho for de 10.000 horas baseado no processo de
definição inadequada, e no atual projeto consume 20.000 horas do resultado,
pode haver um grande impacto em sua organização e na sua empresa.

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.

O Projeto do Descobrimento (1.1.3.P2)

Sem a estrutura apropriada, existe a tendência para que o trabalho de definição
do projeto seja muito longo e sem foco. Definir o trabalho para projetos
grandes toma bastante tempo que deveria ser estruturado como um projeto em
si mesmo. Este é o propósito em definir um projeto separado de
“Descobrimento” do projeto.
Este tem muito sentido, se um projeto necessita de 50.000 horas de esforço,
pode levar um número considerável de meses para elaborar a Definição do
Projeto, documentar e obter a aprovação. Neste caso, estabelecer um projeto
aparte e distinto para definir o projeto. Os deliverables (resultados esperados)
no final de um projeto de “descobrimento” são os seguintes documentos
terminados: A Definição do Projeto, os Procedimentos no Gerenciamento
do Projeto e o Plano de Trabalho (Workplan) para o projeto subseqüente.
Como conseqüência disto, a maioria dos outros deliverables (resultados
esperados) e documentos serão produzidos como parte do projeto seguinte.
Se você achar que a definição de um projeto grande é um projeto em si, você
deverá parar, fazer um levantamento e utilizar os processo de gerenciamento
de projetos para criar um projeto de “Projeto de Descobrir”. Este inclui uma
definição do trabalho (projeto), criar um Workplan e orçamento e
subseqüentemente gerenciar o projeto de descobrir. Novamente, você deverá
ter certeza, você terá que ser bem claro nas expectativas dentro da conclusão
do descobrimento do projeto.
Estimar o esforço e a duração requerida para definir o trabalho. Baseado no
esforço requerido, e categorize o trabalho para defini-lo como pequeno, médio
ou grande usando os critérios descritos anteriormente. Este será o tamanho do
projeto do “descobrimento”. Dependendo do tamanho do projeto do
descobrimento, você de novo terá três opções de como proceder:
1. Para um projeto pequeno de “descobrimento”, pode criar-se uma
Requisição de Serviço, porem não é requerida necessariamente. Para
este tamanho de esforço, apenas continue fazendo o trabalho de definição,
como está descrito no parágrafo 1.1.2 Definir Tarefas / Projetos Médios,
exceto que se deve criar um documento completo de Definição de
Projeto em vez de documento abreviado. Isto é, se você ter definido um
projeto do descobrimento, ao projeto subseqüente o suficientemente
grande para requerer um documento de Definição do Projeto completo.
 2. Para um projeto médio de Descobrimento seguir o processo de
gerenciamento de projetos TenStep para médios projetos. Esse projeto do
descobrimento deve ter uma Definição do Projeto Abreviado e
Workplan do Projeto, e ser Gerenciado adequadamente para alguns
projetos de tamanho médio incluindo Gerenciamento de Incidências,
escopo, risco, etc. (O documento dos Procedimentos no
Gerenciamento de Projeto não necessita ser criado para esse
descobrimento do projeto em si). Quando esse projeto do descobrimento
estiver completo, os documentos; Definição do Projeto, Procedimentos
no Gerenciamento do Projeto, e Workplan do Projeto, estarão
prontos para serem usados no projeto subseqüente. O processo de
aprovação para aqueles documentos é uma parte do projeto do
descobrimento. Desde então a Definição do Projeto aprovada, o projeto
subseqüente pode começar. Neste caso, as steps 1.0 Definir Tarefas e 2.0
Construir o Plano de Trabalho (Workplan) e o Orçamento já estarão
completas (este é o propósito do projeto do descobrimento). O processo
de gerenciamento do projeto para o projeto subseqüente pode começar
com step 3.0 Gerenciar o Plano de Trablaho (Workplan) e o Orçamento.
3. Para um projeto grande de Descobrimento seguir o processo de
gerenciamento de projetos TenStep para Grandes projetos. Por exemplo, Você
pode tentar definir um projeto muito grande ou um programa (um grupo de
projetos relacionado) com tamanho de 50.000 horas de esforço e requerer um
projeto de descobrimento de 5.000 horas de esforço. Nesse caso, o projeto do
descobrimento necessita de definição e gerenciamento similar a de um projeto
grande. Em outras palavras, você deve usar as steps de 1 a 10.
1.2 Definir Tarefas / Técnicas

Trabalhe na Definição do Projeto e no Workplan Simultaneamente

(1.2.P1)
Não há necessariamente uma ordem seqüencial entre a definição do trabalho e
a criação do workplan. Isto é, você não necessita definir completamente o
trabalho para então criar o workplan. Observe que algumas das seções da
Definição do Projeto, por exemplo, não podem ser concluídas sem que se inicie
a delinear o projeto do workplan como um todo. Ao mesmo tempo, você não
pode terminar o workplan sem obter acordo sobre a Definição do Projeto. Por
exemplo, você não pode criar o workplan sem obter um acordo de alto nível
sobre os deliverables e o escopo. Definir o projeto envolve também descrever
uma abordagem total do projeto, a qual ajuda para o conhecimento antes que o
workplan possa ser concluído.
Até certo ponto, definir o trabalho e criar o workplan deve ser feito
simultaneamente. Os dois deliverables principais, a Definição do Projeto e o
Workplan do projeto, também devem ser desenvolvidos em paralelo. Você
perceberá que, enquanto coleta informações acerca do escopo e dos
deliverables, você pode começar a delinear um workplan de alto nível. Na
medida em que você coleta mais informações sobre o trabalho, você poderá
obter mais detalhes sobre o workplan. Quando os deliverables, escopo, as
suposições e a abordagem estiverem completos, você deverá ter informações
suficientes para ser capaz de completar um workplan de alto nível. Você pode
então usar o workplan de alto nível para estimar o orçamento, a mão de obra
(esforço) e a duração - os quais, por sua vez, são utilizados para completar a
Definição do Projeto.

Fracionar Projetos Grandes em Partes Menores (1.2.P2)

Para a maioria, os bons tempos dos projetos de cem milhões de dólares
acabaram. Os projetos realmente grandes, são muito difíceis de gerenciar e
executar com sucesso. Há uma série de problemas relacionados ao tamanho:
• O trabalho torna-se menos claro quanto mais distante for o seu futuro. Os
projetos grandes quase sempre são projetos longos e isso os torna muito
difíceis de serem planejados com sucesso.
• Uma vez que o trabalho futuro é menos claro, mais difícil será fazer as
estimativas exatas para o esforço, a duração e o custo.
• As condições do negócio e das técnicas mudam ao longo do tempo,
tornando suposições de planejamento futuras muito incertas. A certeza do
negócio e das técnicas de hoje podem mudar dramaticamente ao longo do
tempo.
• Você se arrisca a perder o apoio da organização se houver um longo
atraso antes da entrega de resultados tangíveis. É muito difícil manter o
entusiasmo organizacional e o apoio durante longos períodos de tempo.
• É muito difícil predizer os requerimentos e disponibilidade de recursos para
um futuro distante. Novamente, isto se inicia na dificuldade de fazer
estimativas exatas na medida em que você avança no futuro.
Em geral, trabalhos muito grandes são muito difíceis e complexos de gerenciar
como um único projeto. A melhor técnica consiste em fracionar o trabalho em
pedaços mais gerenciáveis, considerando cada um como um projeto em si, com
sua própria definição de projeto e workplan.
Por exemplo, um longo esforço de desenvolvimento de TI pode ser fracionado
em projetos seqüenciais separados com base no ciclo de vida. Um projeto é
ajustado para o trabalho de análise. Próximo ao término deste projeto, um
segundo projeto é estabelecido, baseado no que você já sabe, para fazer o
trabalho de design. Então um projeto de construção / teste é iniciado e
finalmente, um projeto para implementação. Outras iniciativas grandes podem
ser fracionadas em projetos menores que podem ser executados em paralelo.
Algumas iniciativas grandes podem ter uma combinação de projetos menores -
alguns dos quais devem ser feitos seqüencialmente e outros que podem ser
feitos em paralelo. Cada equipe trabalhará para terminar seu projeto menor,
mas todo o trabalho será coordenado de modo a que todo o esforço seja bem
sucedido.

Estabelecer um Programa para Coordenar um Conjunto de Projetos

Relacionados (1.2.P3)
Se você fracionar um trabalho grande em um número de projetos relacionados,
ainda há uma necessidade de manter um gerenciamento e uma coordenação
gerais. Esta é a finalidade de estabelecer 'um programa'. Um programa é a
estrutura “Guarda-chuva” estabelecido para gerenciar uma série de projetos
relacionados. Cada projeto possui um gerente de projeto em tempo integral ou
part-time. O programa é liderado por um gerente de programa. O programa
não produz nenhum deliverable de projeto por si mesmo. As equipes de projeto
produzem todos. A finalidade do programa é:
• Fornecer a direção, a orientação e a liderança geral para os projetos.
• Certificar-se de que os projetos relacionados estão se comunicando
eficazmente.
• Fornecer um ponto central de contato e um foco para o cliente e para as
equipes de projeto.
• Determinar como projetos individuais devem ser definidos para assegurar
que todo o trabalho seja concluído com sucesso.
O Cliente Pode Não Saber o Suficiente para Definir o Projeto por
Completo (1.2.P4)
Às vezes, colocamos uma expectativa demasiado elevada na quantidade de
previsão e de visão que os clientes têm. Em muitos casos, o gerente de projeto
irá ao cliente procurando por respostas para ajudar a definir o projeto, e o
cliente não terá toda a informação necessária. Isto acontece a toda a hora, e
não significa que o cliente não saiba o que está fazendo. Em muitos casos,
especialmente em projetos grandes, o cliente tem uma visão de como serão os
resultados finais, mas ainda não pode articular esta visão em deliverables
concretos. Pode também não saber todas as respostas quanto ao escopo ,
riscos, organização do projeto, etc.
Por ter uma informação menos completa, o gerente de projeto pode sentir a
necessidade de adivinhar detalhes. Esta não é uma boa solução. É melhor
indicar de antemão tudo que você sabe, assim como tudo que você não sabe.
Se você for solicitado a apresentar estimativas de trabalho, custos e de
duração, você precisará fornecer uma gama alta e baixa com base nas
incertezas restantes.
Uma outra alternativa é simplesmente fracionar o trabalho em uma série de
projetos menores (como descrito acima). Mesmo que os resultados finais não
possam ser claramente definidos, deve haver alguma quantidade de trabalho
que esteja bem definida e que, por sua vez, irá conduzir à informação
necessária para a solução final. Você deve definir um projeto que abranja
somente aquilo que você pode confortavelmente ver hoje. Então defina e
planeje os projetos subseqüentes para abrangerem o trabalho restante na
medida em que mais detalhes forem conhecidos. Por exemplo, você pode criar
um projeto para coletar as exigências do negocio, e então usar os resultados
deste projeto para definir o segundo projeto para construir os deliverables
finais.
Se não for permitido que você fracione o projeto em partes menores, você deve
ao menos saber o suficiente para poder planejar o trabalho para os primeiros
90 dias. Nesta terceira abordagem, você planeja o trabalho em curto prazo
mais detalhadamente, e deixa o trabalho de longo prazo indefinido. A cada mês
você deve redefinir e planejar o trabalho restante. Na medida em que você
descobrir mais e mais informações, você poderá planejar o trabalho restante
em um nível mais detalhado. Na medida em que for descoberto mais detalhes,
você pode redefinir as suas estimativas e trabalhar junto com o patrocinador
para assegurar que o projeto poderá prosseguir.

Organização do Projeto - Funções e Responsabilidades (1.2.P5)

Em projetos pequenos, a organização é bastante simples - talvez apenas o
gerente de projeto e o cliente / patrocinador. A pessoa que está gerenciando o
projeto pode ser também a única pessoa que realmente trabalhe no projeto.
Entretanto, em projetos grandes, pode existir uma estrutura organizacional
elaborada e formal. Você pode ter membros de equipe, um patrocinador
executivo, um patrocinador de projeto, um gerente de clientes, um diretor de
projeto, um comitê de direção, vendedores, clientes, e outros envolvidos. Você
não deseja tornar as coisas demasiado complexas, mas quanto mais pessoas
estiverem envolvidas no projeto, mais importante será que todos sejam
esclarecidos com relação a suas funções e responsabilidades. Por exemplo, a
última coisa que você deseja é ter pessoas lhe dando instruções como se
fossem o patrocinador, quando realmente podem ser apenas grupos
interessados de gerenciamento. Você também não quer pessoas agindo como
membros da equipe quando na verdade as mesmas são stakeholders.
Um dos aspectos relativos à definição do projeto é a estrutura da organização e
quais são as funções e as responsabilidades de todos os principais
participantes. Geralmente, as funções e as responsabilidades características
podem ser definidas antecipadamente para sua organização, e então
reutilizados de acordo com cada projeto. Muitas das funções e das
responsabilidades comuns do projeto estão esboçados em 1.2.2 Definir Tarefas
/ Funções e Responsabilidades.

Aprovações do Projeto (1.2.P6)

Uma vez que o projeto esteja definido, o gerente de projeto deve procurar a
aprovação formal do patrocinador e dos grupos interessados de gerenciamento.
Há muitas maneiras de obter a aprovação formal do projeto. Como a maioria
das outras atividades no TenStep Processo de Gerenciamento de
Projetos®, um pouquinho de planejamento, é a chave. Para projetos
pequenos, uma assinatura do cliente principal ou do patrocinador do projeto
provavelmente será suficiente para demonstrar a aprovação do trabalho a ser
iniciado. Esta aprovação poderá ser também através de confirmação por e-mail.
Porém não deve ser verbal.
Para projetos maiores, pergunte ao seu gerente e ao patrocinador do projeto
quem deve dar a aprovação explícita da definição do projeto, quem deve dar a
aprovação implícita e quem necessita de uma cópia somente para finalidades
informativas. Em geral, utilize a seguinte abordagem como seu ponto de
partida.
• Patrocinador do projeto e stakeholders chave. Obtenha uma
aprovação explícita. Esta aprovação pode ser uma assinatura formal em
uma cópia em papel da definição do projeto. Poderia ser também um e-
mail que indique especificamente a aprovação. Você pode também ter
algum tipo de aprovação formal do fluxo de trabalho. A chave é que a
aprovação é explícita e que você guarde algum registro da mesma.
• Outros stakeholders de gerenciamento. Obtenha uma aprovação
implícita. Implícita significa que você supõe que eles aprovam a definição
do projeto, exceto se eles a devolverem para você. Primeiramente você
enviaria uma cópia “soft” (eletrônico) ou “hard” (papel) da definição do
projeto. Deixe-os saber que você gostaria que eles avaliassem o material e
fornecessem o “feedback”, especialmente se eles tiverem perguntas ou
algumas preocupações. Dê-lhes uma data para resposta, e deixe-os saber
que se você não tiver retorno deles até esta data, você irá supor que estão
concedendo sua aprovação. Se devolverem com preocupações, resolva-as
ou leve-as ao patrocinador do projeto para uma resolução.
• Outras partes interessadas. Envie uma cópia da definição do projeto e
deixe saber que é somente para informação. Você deve estar disponível
para discutir qualquer conteúdo, de modo que possam melhor
compreender o material, mas não para sua aprovação.
Estabelecer a Restrição Tripla (1.2.P7)
No final do processo da definição e do planejamento (nos passos 1 e 2 da
metodologia TenStep) você deve ter um acordo com o seu patrocinador sobre o
trabalho que será realizado e o custo (tempo) e a duração que serão
necessários para concluir o trabalho. Estes três itens dão forma então a um
conceito chamado "Restrição Tripla". O aspecto chave da restrição tripla é que
se um dos três itens mudar, obrigatoriamente no mínimo mais um dos três
itens necessitará ser mudado também. (A restrição tripla pode ser escrita de
varias maneiras similares. O item custo também pode ser referido como
esforço, que faz sentido se os custos de mão de obra forem todos internos e se
não houver custos para os itens não relacionados diretamente com os custos de
mão de obra. Às vezes, o item escopo é referido como qualidade, que focaliza
então em entregar um determinado nível da qualidade com um custo e uma
duração predeterminado. Estes aspectos são mais limitados da restrição tripla,
mas os conceitos gerais continuam verídicos.)
Este é um conceito fácil de visualizar se
você pensar na restrição tripla como um
triângulo, com os lados que representam
o custo, a duração e o escopo do
trabalho.
Se o escopo do trabalho aumentar, o
custo e / ou o prazo devem aumentar
também. Isto faz sentido. Se você tiver
mais trabalho a fazer, este trabalho
necessitará de um custo (esforço)
adicional e talvez de uma duração mais
longa. (do mesmo modo se você reduzir o
escopo do trabalho, o custo (esforço) e /
ou o prazo devem diminuir também.)
Se você fosse solicitado para acelerar o
projeto e concluir mais cedo do que o
programado, seria também lógico para
você solicitar menos trabalho. Entretanto,
se você for solicitado para entregar o
mesmo trabalho em menos tempo, o
terceiro pé da restrição tripla deve
aumentar para manter o contrapeso. Isto
também deve fazer sentido. Você
necessitará aumentar os custos (esforços)
através de horas extras ou talvez
alocando mais recursos para concluir mais
cedo a mesma quantidade de trabalho.
Plano do Projeto (Project Book) (1.2.P8)
O Plano do Projeto é um único deliverable que pode ser criado para armazenar
todos os vários documentos de gerenciamento do projeto que foram criados nos
passos 1.0 definir Tarefas e 2.0 Construir o Plano de Trabalho (Workplan) e
Orçamento do (TenStep Processo de Gerenciamento de Projetos®). Embora os
documentos possam certamente ser referenciado individualmente, o Plano do
Projeto pode ser usado para agrupá-los todos. O Plano do Projeto inclui
especificamente:
• Definição do Projeto (Também chamado de Project Charter e / ou
Declaração do Escopo do Projeto).
• Declaração do Escopo, Estimativas dos custos, esforços e Duração.
• Papeis e Responsabilidades, etc.
• Workplan (Cronograma), Estrutura de Decomposição do Trabalho (Work
Breakdown Structure), Marcos (Milestones).
• Procedimentos de Gerenciamento do Projeto.
• Plano de Gerenciamento do Escopo, Cronograma e Plano de
Gerenciamento dos Custos.
• Plano de Gerenciamento da Qualidade, Plano de Gerenciamento dos
Recursos Humanos.
• Plano de Comunicações, Plano de Gerenciamento dos Riscos.
• Aprovações do Projeto.
• Outros documentos de gerenciamento do Projeto.
O Plano do projeto pode ser um documento atual, um fichário ou um arquivo
manual. Por exemplo, você poderia obter um arquivo de dois-anéis para
armazenar todos estes documentos e o arquivo poderia ser chamado de Plano
do projeto (Project Book). Você poderia também criar uma pasta arquivo dentro
de um Server (Computador) chamado de Plano do Projeto e colocar cópias
eletrônicas de todos os deliverables que se encontram dentro do arquivo
manual.

Tente compreender as necessidades expressadas do seu cliente e as

suas necessidades reais (1.2.P9)
A definição do projeto descreve o projeto em um nível elevado. A definição do
projeto descreve especificamente as necessidades do cliente, também as
estimativas fornecidas pela equipe do projeto sobre o esforço, duração e custo
necessário para cumprir estas necessidades. Então, os detalhes das
necessidades do cliente são definidas mais detalhadamente através do
recolhimento de exigências do negócio.
É importante que o gerente e a equipe do projeto compreenda que as
verdadeiras necessidades do cliente podem não ser as mesmas que lhe são
expressadas e que estas são a fundação da definição do projeto e das
exigências do negócio. Em muitos casos, o cliente não compreende suas
necessidades verdadeiras quando o projeto começa. As necessidades
verdadeiras podem às vezes evoluir sobre o curso do projeto. Do mesmo modo,
o cliente pode ter uma visão desobstruída de suas necessidades, mas pode ter
uma grande dificuldade para expressar as suas necessidades a equipe do
projeto. Até certo ponto, esta é a finalidade do gerenciamento das mudanças do
escopo – para permitir que o cliente mude as exigências do projeto quando o
projeto estiver em andamento.
A equipe do projeto pode não fazer nada melhor do que documentar as
necessidades expressadas do cliente e usar estas necessidades como base para
obter a aprovação dos documentos Definição do Projeto e Exigências do
Negócio. Entretanto, é também verídico que a equipe do projeto deve fazer um
trabalho tão bom quanto possível para descobrir as necessidades reais do
cliente. Isto envolve técnicas tais como fazer boas perguntas, e dar continuação
com perguntas mais especificam, recolhendo as informações de todos os
Stakeholders chaves e fazendo mais perguntas quando as exigências não
parecerem fazer sentido, etc. Obviamente, a equipe do projeto deve fazer o que
for necessário para tentar descobrir as verdadeiras necessidades do cliente.
Quanto mais próximas forem as verdadeiras necessidades do cliente com as
necessidades expressadas, mais próximo você estará de completar certo o
projeto na primeira vez.

1.3 Definir Tarefas / Deliverables (Resultados Esperados)

Tamanho Informação Requerida

Deliverables: Requisição de Serviço

(Nota: Este é provavelmente um documento de uma a duas páginas. Não
se requer de algo mais longo.)
Número de Requisição de Serviço (opcional): Este número identifica e
conecta o trabalho a qualquer outro processo ou software que necessita um
numero de seguimento.
Projeto
Prioridade (opcional): A recomendação de cliente em termos de prioridade
Pequeno alta, media a baixa.
Nome do Projeto / Aplicação: O nome do projeto. Se for uma requisição de
melhora de um software ou produto, então se refere ao sistema ou produto
existentes.
Declaração de Escopo: Descreve as tarefas que estão sendo requeridas. Seja
o mais especifico possível a referir-se a novo trabalho ou melhoras requeridas.
Motivo da Requisição de Serviço (Opcional): descreve os benefícios de
 realizar este trabalho.
Designado a: Geralmente se mencionam as pessoas as quais designarão este
trabalho. Esta conformação, freqüentemente se desconhecem ao inicio, porem
deve ser designado posteriormente.
Habilidades Necessárias (Opcional): Descreve as habilidades requeridas para
executar com êxito este requerimento.
Estimado de Horas e Custo de Esforço: Para projetos pequenos esta
informação será bastante razoável. Posto que não tem muitas tarefas, existiram
poucas incógnitas que podem afetar um estimado certo. O gerente de projeto
ou um membro conhecedor da equipe de trabalho pode completar esta
informação.
Duração Estimada: Indicar o tempo que tomará para terminar o trabalho uma
vez iniciado.
Aprovação #1 / Data: Assinatura do cliente indicando que as tarefas
relacionadas com esta Requisição de Serviço podem começar. (Assegurar que o
cliente acorde que a prioridade deste trabalho é o suficientemente alto para
começar).
Aprovação #2 / Data: (Opcional) Autorização (assinatura) indicando que o
cliente esta de acordo que o resultado deste trabalho pode entrar em produção
ou operação.
Aprovação #3 / Data: Assinatura do cliente indicando que o trabalho teve o
termino bem sucedido.
** Buscar documento ‘Requisição de Serviço’ em Biblioteca de Moldes
(Templates)**

(1) Deliverable (Resultado Esperado)-: Definição Abreviada

de Projeto
Visão Geral do Projeto: Descreve o propósito do projeto e a razão por a qual
se esta solicitando.
Escopo: Define os deliverables (resultados esperados) que se criarão com este
projeto e forneça uma explicação relacionada como serão esses deliverables.
(em outras palavras uma breve descrição dos mesmos). Para obter informação
mais detalhada, ver 5.1.1 Definir Escopo.
Horas Estimadas de Esforço: Estimar as horas requeridas. Fornecer
informação sobre a maneira em a qual se obteve o preparo estimado e
Projeto suposições que foram considerados. Para mais informação, ver 2.1.1 Construir o
Médio Workplan / Processos / Estimação.
Custo Estimado: Estimar o custo do trabalho, tomando como base as Horas
Estimadas. Agregue qualquer gasto não relacionado com trabalho, tais como
equipamento, Hardware - Software, treinamento, alojamento, viagens, etc. Mais
informação ver 2.1.1 Construir o Workplan / Processos / Estimação.
Duração Estimada: Estimar a duração do projeto, uma vez iniciado. Conhece-
se a data de inicio também se poderá indicar uma data do termino. Mais
informação ver 2.1.1 Construir o Workplan / Processos / Estimação.
Suposições Principais: São as suposições dos eventos externos que devem
ocorrer para completar com êxito o projeto. Se for alta a probabilidade dos
eventos ocorrerem, eles devem ser identificados como Suposições. Estas podem
ser identificadas mediante a experiência do conhecimento de quais atividades
ou eventos que provavelmente ocorreram na organização, mediante sessões de
chuva de idéias (brainstorming) com os clientes, responsáveis (Stakeholders) e
membros de equipe e analisando os itens identificados como de baixo risco
 durante o processo de Gerenciamento de Riscos. Para mais informações, ver
7.1.1 Gerenciar os Riscos / Processo / Suposições.
Riscos Principais: Riscos são os futuros, eventos externos que causarão
problemas para o projeto se eles ocorrerem. Se for alta a probabilidade dos
eventos ocorrerem, eles devem ser identificados como Riscos. Para melhor
informação ver 7.1 Gerenciar os Risco / Processo.
Aprovações: Listar os nomes e cargos das pessoas que devem aprovar este
documento. Ver 1.2 definir Tarefas / Técnicas para determinar algumas opções
de como obter estas aprovações.
** Buscar documento ‘Definição Abreviada de Projeto’ em Biblioteca de Moldes
(Templates) **

(2) Deliverable (Resultado Esperado) -: Procedimentos de

Gerenciamento de Projeto
Este documento contém os procedimentos que serão usados para gerenciar o
projeto. Inclui as seções sobre: Gerenciamento de Incidências, troca de Escopo,
Comunicações, Riscos, Qualidade e Estatísticas - Métricas. (Pontos de referencia
e partida para estes procedimentos poderão ser encontrados nos seguintes
passos do Processo TenStep)
** Buscar documento ‘Procedimentos de Gerenciamento de Projeto’ em
Biblioteca de Moldes (Templates) **

(1) Deliverable (Resultado Esperado) -: Definição do

Projeto
Resumo Executivo: O documento completo de definição do projeto tende a
ser muito longo e de difícil digestão para os executivos. Inclua um Resumo
Executivo para facilitar a compreensão desta definição. Este resumo é uma
visão de documento completo Definição de Projeto, não é um resumo de
projeto.
Visão Geral do Projeto: Descreva o propósito do projeto e os benefícios do
negocio. Também explicar porque o projeto tem prosseguimento agora, outras
iniciativas e algumas informações histórica. Comparta quaisquer objetivos e
metas de negocio que este projeto tentara obter.
Objetivos do Projeto: Indique os objetivos que o projeto alcançará. Os
objetivos do projeto devem apoiar as metas e os objetivos de negocio. Os
Projeto deliverables (resultados esperados) produzidos no projeto devem apoiar os
Grande objetivos do projeto. Para a informação adicional sobre metas e objetivos, ver
1.2.1 Definir Tarefas / Técnicas / Metas e Objetivos.
Escopo de Projeto: Defina os deliverables criados por este projeto e forneça
uma explicação relacionada como serão esses deliverables. (em outras palavras
uma breve descrição dos mesmos) Também clarifique as informações que o
projeto não produzira. Em outras palavras, É decidir que está fora de escopo? É
muito importante estar claro sobre que coisas se poderiam produzir no projeto,
porem não serão produzidos. Este será muito mais fácil manejar as trocas de
escopo durante a execução do projeto. Em adicional, descreva o escopo em
termos mais específicos, tais como:
• Os dados que serão trabalhados no projeto e que dados estarão fora do
escopo de projeto.
• Que organizações serão afetadas e quais não serão.
• Que processos de negocio estarão dentro do escopo e quais estarão fora
 do escopo.
• Que transações estarão dentro do escopo e quais estarão fora do escopo.
• Que outros projetos se verão impactados e quais permanecerão
inalterados ou sem impacto.
• Qualquer outro aspecto dentro do escopo ou fora do escopo que tem que
ser levado em conta.
Para mais detalhes ver 5.1.1 Definir Escopo.
Horas Estimadas de Esforço: Estimar as horas requeridas. Fornecer
informação sobre a maneira em a qual se obteve o preparo estimado e
suposições que foram considerados. Para mais informação, ver 2.1.1 Construir o
Workplan / Processos / Estimação.
Custo Estimado: Estimar o custo do trabalho, tomando como base as Horas
Estimadas. Agregue qualquer gasto não relacionado com trabalho, tais como
equipamento, Hardware - Software, treinamento, alojamento, viagens, etc. Mais
informação ver 2.1.1 Construir o Workplan / Processos / Estimação.
Duração Estimada: Estimar a duração do projeto, uma vez iniciado. Conhece-
se a data de inicio também se poderá indicar uma data do termino. Mais
informação ver 2.1.1 Construir o Workplan / Processos / Estimação.
Suposições Principais: São as suposições dos eventos externos que devem
ocorrer para completar com êxito o projeto. Se for alta a probabilidade dos
eventos ocorrerem, eles devem ser identificados como Suposições. Estas podem
ser identificadas mediante a experiência do conhecimento de quais atividades
ou eventos que provavelmente ocorreram na organização, mediante sessões de
chuva de idéias (brainstorming) com os clientes, responsáveis (Stakeholders) e
membros de equipe e analisando os itens identificados como de baixo risco
durante o processo de Gerenciamento de Riscos. Para mais informações, ver
7.1.1 Gerenciar os Riscos / Processo / Suposições.
Riscos Principais: Riscos são os futuros, eventos externos que causarão
problemas para o projeto se eles ocorrerem. Se for alta a probabilidade dos
eventos ocorrerem, eles devem ser identificados como Riscos. Para cada risco
identificado, inclua um plano especifico que mostrara como você planeja
gerenciar o risco. Estas atividades de gerenciar os riscos devem ser incluídas
dentro o documento do Workplan do projeto. Para melhor informação ver 7.1
Gerenciar os Risco / Processo.
Abordagem: Descreva em palavras a informação contida no Workplan (Plano
de Trabalho). Esta informação é para o beneficio do cliente e qualquer outra
pessoa responsável (Stakeholders), a quem não lhe seria fácil interpretar todas
as atividades descritas no Workplan. Descreva as fases principais do projeto e
Milestones e uma seqüência geral do trabalho. Comunique quando os
deliverables Principais (resultado esperados) serão produzidos. Explique
qualquer técnica interessante que se usará no projeto, como por exemplo
Desenrolo Acelerado de Aplicações (RAD-Rapid Application Development),
Seções Comuns e Compartidas de Design (JAD - Joint Application Design), etc.
Dependendo do tamanho do projeto, esta seção pode ser bastante extensa.
Para obter mais idéias de como abordagem pode ser descrita ver 2.1.3
Construir o Workplan / Abordagem.
Organização do Projeto: O organograma para projetos de grande tamanho
usualmente pode ter muitas “caixas” refletindo o envolvimento dos vários
stakeholders. Por exemplo, O projeto pode ter formalmente um Gerente de
Projeto dentro da organização do cliente que também reporta a o Patrocinador
(Sponsor) do projeto. Pode existir um Sponsor executivo, como também um de
menor nível (Sponsor do Projeto), que representa anterior e no dia - a - dia.
Outros responsáveis (Stakeholders) podem estar organizados em Comitês de
 Direção (Steering Comitês) para prover guias estratégicas ao projeto.
Supridores e Vendedores poderiam ter uma função formal e querer ser
representados na estrutura organizacional do projeto. As três (3) formas
principais de organização da equipe do Projeto descrevem-se na seção 1.2.4
Definir Trabalho / Organização de Projeto. Você pode também incluir uma
matriz de responsabilidades que mostram responsabilidades chaves para cada
função associado com os deliverables principais (resultados esperados)s. Para
melhores informação ver 1.2.3 Definir Trabalho / Matriz de Responsabilidade.
Muitas das Funções específicas do projeto se detalham na seção 1.2.2 Definir
Trabalho / Função e Responsabilidades.
Pagina de Aprovações: Liste os nomes e cargos das pessoas que serão
necessários para a aprovação do documento. Para técnicas e opções para obter
aprovações, veja 1.2 Definir Tarefas / Técnicas.

** Busca o documento ‘Definição de Projeto’ em Biblioteca de Moldes

(Templates) **

(2) Deliverable (Resultado Esperado) -: Procedimentos de

Gerenciamento de Projeto
Este documento contém os procedimentos que serão usados para gerenciar o
projeto. Incluem as seções sobre: Gerenciamento de Incidências (problemas),
de trocas de Escopo, Comunicações, Risco, Qualidade e Estatísticas – Métricas.
(Pontos de referencia e partida para estes procedimentos poderão ser
encontrados nos seguintes passos do Processo TenStep)
**Busca ‘Procedimentos de Gerenciamento de Projeto’ em Biblioteca de Moldes
(Templates) **

**Templates Associados**

1. Templates Básicos - Gratuitos

• Requisição de Serviço
• Definição Abreviada do Projeto
• Definição do Projeto
2. Templates Avançados - Incluídos nos produtos TenStep PGP Lite & Pro e
TenStep PB Lite & Pro
• Procedimentos no Gerenciamento de Projetos
• Project Plan
• Project Responsibility Matrix
3. Templates Suplementares - Incluídos nos produtos TenStep PGP Pro e
TenStep PB Pro
• Business Case
• Business Plan
• Planning Compliance Checklist
• SWOT Analysis
• Team Directory