(Este conteúdo suplementar faz parte da metodologia TenStep Processo de
Gerenciamento de Projetos®)
O Plano
de Trabalho (Workplan) do Projeto é criado juntamente com a Definição do
Projeto a partir do Step 1.0 da metodologia TenStep PGP. Isto pode ser
obvio, mas o Plano de Trabalho (Workplan) é uma ferramenta vital para
assegurar que a equipe de projeto tem conhecimento do que eles
necessitam fazer. Pode parecer óbvio, mas o
plano de trabalho é uma ferramenta essencial para garantir que a equipe
de projeto saiba o que deve fazer. Muitas pessoas não se sentem a
vontade para criar um plano de trabalho. Normalmente isto ocorre porque
o projeto não foi bem definido. Como pode ser construído um plano de
trabalho decente se o Gerente de Projeto não está absolutamente seguro
do que o projeto irá oferecer?
No step
1.0 Definir Tarefas
da metodologia TenStep PGP®, você definiu o projeto para assegurar que
você tem um acordo com o patrocinador (Sponsor) sobre qual o trabalho
deveria ser completado até o final do projeto. Neste step, o gerente do
projeto determina como este trabalho vai ser realizado. Abordagens
diferentes podem ser aplicadas neste step de acordo com o tamanho do
projeto. O plano de Trabalho (Workplan) para projetos pequenos pode ser
construído sem muita formalização. Para auxiliá-lo nos projetos, pode-se
usar deste pacote de softwares de gerência de projetos como, MS Project,
planilhas eletrônicas (Excel), até caneta e folhas de papel.
Há
várias técnicas para construir o plano de Trabalho (Workplan). Talvez a
melhor alternativa é utilizar um plano de trabalho (Workplan) de projeto
similar anterior, para um ponto de partida. Mas, porque os projetos são
de naturezas únicas, este pode ser difícil.
A
segunda boa alternativa é procurar um template de um plano de trabalho (Workplan)
usado anteriormente com características similares. Por exemplo, você tem
um projeto para instalar um pacote de software. Apesar de ser a primeira
vez que este pacote de software particular vai ser implementado em sua
empresa, você pode procurar um template genérico para um projeto de
implementação de um pacote de software.
Se você
não tiver um template de um plano de trabalho (Workplan) usado
anteriormente para usar no ponto de partida, a técnica de EAP (Estrutura
Analítica do Projeto)
deve ser usada. A EAP é uma técnica para ter uma visão do projeto em um
alto nível e subseqüentemente dividir os trabalhos em partes menores até
você obter uma visão do trabalho requerido. Toda a equipe envolvida no
projeto pode participar deste exercício. Se você não tem informações
suficientes para criar um EAP para todas fases do projeto, você pode
usar a técnica de Rolling Wave Planning (RWP). Neste caso, você terá que
construí um EAP bem definido da primeira fase do projeto e quando esta
fase estiver quase completa, você terá informações suficientes para
construí um EAP bem definido para a fase seguinte. Então você continuara
este processo até o final do projeto.
Calculando o Limiar
- Visão Geral
(2.1.2.P1)
O
processo de criação de uma
estrutura analítica do projeto
(EAP), requer um processo repetitivo
de fracionar partes maiores do
trabalho em uma série de partes cada
vez menores.
Uma pergunta apropriada é, até que
tamanho as atividades devem ser
fracionadas. A resposta a essa
pergunta é o limiar para o
fracionamento do trabalho e não fará
sentido fracioná-lo ainda mais. Não
há nenhuma regra rígida e fixa para
o limiar, mas há algumas diretrizes
gerais e então algumas advertências
que poderão ser aplicadas.
Geralmente para projetos grandes,
qualquer parte do trabalho que for
superior a 80 horas de empenho
deverá ser fracionada em partes
menores. Em outras palavras, não
deverá haver nenhuma atividade no
cronograma com a duração superior a
80 horas. Contudo, para os projetos
de tamanho médio ou pequeno, o
limiar poderá ser menor e
provavelmente será menor. Se o seu
projeto for de tamanho médio, as
atividades não deverão ser maiores
que 40 horas. Se o projeto for
pequeno, fracione as atividades em
trabalhos menores que 20 horas.
Lembre-se de que o limiar que você
estabeleceu é o limite máximo e você
poderá fracionar as atividades
menores de acordo com as suas
necessidades.
Há duas advertências para você ter
em mente.
-
É possível que as atividades que
serão trabalhadas em um futuro
distante, não possam ser
fracionadas o suficiente para
atender o limiar, porque poderá
haver muitas coisas
desconhecidas sobre elas. Se
esta incerteza envolver somente
algumas atividades, então você
poderá deixar o trabalho em um
nível superior. Contudo, se for
difícil para definir e estimar a
maior parte do trabalho futuro,
a melhor abordagem será
fracioná-lo em um projeto
separado, fora do escopo que já
está atualmente sendo planejado.
Por exemplo, poderá ser difícil
planejar e estimar o trabalho
das fases de construção e de
testes de um projeto sem
primeiramente definir as
exigências do negócio. Nesse
caso, a melhor abordagem é
definir um projeto inicial para
reunir as exigências do negócio,
como um segundo projeto de
acompanhamento para projetar,
construir e testar a solução.
Com base nos resultados do
primeiro projeto, o segundo
projeto poderá ser esboçado e
estimado com maior precisão.
Dito isso, se você não tiver a
opção de múltiplos projetos,
este trabalho futuro poderá ser
deixado em um nível mais alto do
que o limiar. O risco é que,
quando este trabalho se
aproximar, as estimativas terão
uma margem de erro maior e você
terá que lidar com as
conseqüências de exceder o prazo
final e o orçamento do seu
projeto. A reserva de
contingência para as estimativas
pode ser aumentada para
gerenciar as incertezas do
trabalho futuro.
-
Uma das razões para fracionar
atividades em partes menores é
para saber claramente o que deve
ser feito. Se uma atividade for
bastante óbvia para a pessoa que
for designada, então essa
atividade não necessitará ser
fracionada além do limiar. Por
outro lado, se o trabalho não
for bem conhecido pela pessoa
designada, então o trabalho
poderá ser fracionado além do
limiar para fornecer maior
clareza a essa pessoa. Por
exemplo, se uma atividade que
foi calculada para ser concluída
em 70 horas nunca foi executada
antes, a mesma poderá necessitar
ser fracionada em uma série de
atividades menores para garantir
que as pessoas designadas saibam
exatamente o que deve ser feito.
Estes dois fatores - a habilidade
para gerenciar eficazmente o
trabalho e a habilidade para
entender o trabalho requerido -
devem dirigir sua decisão sobre o
quão pequeno as atividades deve ser.
Atividades Sumárias
(2.1.6.P2)
Se você observar as atividades da
EAP e determinar que uma delas
necessita ser fracionada em um nível
mais baixo, a atividade original se
torna conhecida como um nível
"sumário". Uma atividade sumária não
tem trabalho ou horas associadas
especificamente a ela. Uma
atividade sumária somente representa
um enrolar lógico das atividades que
estão abaixo dela. Quando você
construir o plano de trabalho (Workplan),
você necessitará somente incluir as
atividades detalhadas e não as
atividades sumárias. Entretanto,
para que seja claro e legível,
freqüentemente também faz sentido
incluir estas atividades sumárias no
plano de trabalho (workplan). Se uma
atividade sumária incluir a
construção e a conclusão de um
deliverable principal, esta
atividade sumária poderá também
representar um marco (milestone).
Como você decidiu fracionar uma
atividade sumária em tarefas
menores, não faz sentido ter somente
uma tarefa detalhada abaixo da
atividade sumária. Se você tiver
este caso em sua EAP, você deve:
-
Fracionar a atividade detalhada
em duas ou mais tarefas menores,
ou
-
Livrar-se da tarefa detalhada e
associar o trabalho a atividade
sumária – que agora se
transforma em uma tarefa
detalhada.
Uma outra regra para as atividades
sumárias é que uma vez que as
atividades detalhadas forem
concluídas, todo o trabalho
representado pela atividade sumária
também deve ser terminado. Se houver
exigências de mais trabalho, as
atividades adicionais devem ser
acrescidas abaixo da atividade
sumária.
Utilize a abordagem
antiga – blocos de papeis adesivos amarelo (Post-its™)
(2.1.6.P3)
|
 |
É espantoso o número de pessoas que utilizam blocos de papeis
adesivo amarelo (post-its™) e uma parede branca para criar o
primeiro esboço da estrutura analítica do projeto (EAP).
Esta técnica é muito fácil. Você inicia reunindo as pessoas
apropriadas em uma sala. Estas pessoas são os integrantes da
equipe do projeto e os clientes que têm conhecimento da
construção de uma EAP. Tipicamente você inicia escrevendo os
nomes dos deliverables principais na folha adesiva amarela (um
deliverable por folha) e certifica-se que os participantes
concordam. Se algum dos deliverables principais for muito
grande, você poderá criar novas folhas adesivas amarelas que
descrevam as atividades ou
pacotes de trabalho
que são necessários para criar o deliverable principal. Estas
atividades ou pacotes de trabalho
são colocados abaixo do deliverable principal. Se as atividades
ou
pacotes de trabalho também forem grandes,
você deverá continuar o processo de decomposição até que as
atividades
ou pacotes de trabalho
estejam em um nível que você possa compreender o que é
necessário para construí-los. Em geral, dois níveis devem ser
suficientes. |
A seguir,
descreva as atividades que devem
ocorrer para completar cada
deliverable. Cada atividade deve
aparecer em uma folha adesiva
separada. Estas são novamente
organizadas abaixo do deliverable
correspondente. Se você souber em
que ordem as atividades deverão ser
concluídas, você poderá organizar as
folhas adesivas em seqüência.
Contudo, isto não é importante neste
momento, o importante é identificar
todo o trabalho.
Observe as atividades de cada
deliverable e estime o trabalho
associado. Se o esforço associado a
uma atividade for maior do que seu
critério de limiar estabelecido no
passo
5.3.02.1TS Calculando o Limiar,
fracione esta atividade em
atividades menores. Cada uma destas
novas atividades é representada
através de uma nova folha adesiva
abaixo da atividade original, e
passa a ser uma atividade sumaria.
Continue com este processo até que o
trabalho requerido para concluir
todos os deliverables esteja
definido. Os deliverables poderão
não ter a mesma quantidade de níveis
de atividades. Alguns dos
deliverables simples podem atender
os critérios de limiar em um ou dois
níveis. Outros podem necessitar de
três ou quatro níveis. (para maiores
detalhes sobre os critérios de
limiar veja
5.3.02.1TS Calculando o Limiar)
A vantagem desta abordagem é que a
sua equipe pode visualizar o
trabalho, e pode ajudar a garantir a
identificação de todo trabalho para
concluir o projeto. As folhas
adesivas amarelas possibilitam que
você movimente facilmente as coisas.
Se você acrescentar uma atividade e
então decidir removê-la, você
simplesmente remove a folha amarela.
Da mesma forma, se um deliverable ou
um grupo de atividades estiver no
lugar errado, você simplesmente
movimenta as folhas adesivas para
onde elas devem estar.
Quando você
tiver feito tudo isso, você poderá
inserir as atividades sumárias e as
detalhadas em sua ferramenta de
gerenciamento de Projetos. (por
exemplo,
MSProject,
RiskyProject,
cOrdin8,
etc.)
Uma Abordagem Comum é para Identificar as Entregas do Primeiro e do
Segundo Nível, e então identificar as atividades para os níveis
subseqüentes.
(2.1.6.P4)
Às vezes as pessoas têm dificuldades
para iniciar uma EAP (Estrutura Analítica do Projeto),
porque não estão seguras do que colocar no topo, e não sabem
como fracionar o trabalho a partir daí. Embora exista muitas
maneiras de iniciar uma EAP, no final das contas você quer
focalizar nas entregas. Supomos que o nível superior é o
projeto em geral (nível 0), o nível seguinte terá que
descrever as entregas principais. Depois que as entregas
forem descritas, as atividades necessárias para construir as
entregas podem ser definidas. O cronograma do projeto é
composto por atividades, mas estas devem ser desenvolvidas
num contexto para completar as entregas.
Existe várias opções para definir uma
EAP no nível 1 (abaixo do topo nível 0).
-
Pode fazer sentido colocar as
entregas principais do projeto diretamente no nível 1, e
se necessário, fracioná-las em componentes menores no
nível seguinte.
-
Uma outra opção para o nível 1, é
descrever as organizações que serão envolvidas, como
departamento de vendas, marketing, TI, etc. O nível
seguinte deve descrever as entregas que cada organização
produzirá.
-
Uma terceira opção é observar o
nível 1 em termos do ciclo de vida do projeto. Por
exemplo, análise, design, construção e testes. Outra
vez, se esta for a melhor maneira para observar o nível
1, então, o nível 2 deverá descrever as entregas
produzidas em cada estágio do ciclo de vida.
Você percebeu que o nível superior
(nível 1) pode iniciar com entregas
ou com uma
outra maneira de agrupar logicamente as partes principais do
projeto. Contudo, se você escolher uma outra maneira para
organizar seu pensamento sobre o projeto, você deverá passar
imediatamente para as entregas, e depois para as atividades
necessárias para construir as entregas.
Para maiores informações, veja
5.3.01.1TS Exemplos da EAP.
Utilize esta
Técnicas Adicionais para Fracionar as Atividades Sumários
(2.1.5.P5)
Quando uma equipe ta criando uma EAP,
normalmente ocorrem algumas duvidas sobre até que nível a
estrutura analítica do projeto deve ser fracionada.
Por exemplo, quando devemos parar de decompor o trabalho?
Quando uma atividade já foi suficientemente fragmentada?
Parte da resposta a estas perguntas, seria utilizar um
critério de limiar para estimar as atividades,
como descrito na seção
5.3.02.1TS Calculando o Limiar. Outros pontos a
considerar são:
-
A atividade deve conter as
sub-atividades que são relacionadas e contínuas. Por
exemplo, se você tiver uma atividade chamada “Criar a
Estratégia de Testes e Treinamento”, esta
atividade provavelmente deverá ser fragmentada cada vez
mais, pois as Estratégias de Teste e de Treinamento não são
necessariamente relacionadas, e não são necessariamente
contínuas.
-
A atividade deve ser completada
por uma pessoa ou por um grupo de pessoas. Se você tiver
uma atividade que exija pessoas diferentes para
completar as sub-atividades diferentes, então esta
atividade deverá ser ainda mais fragmentada em sub-atividades de maneira que uma pessoa ou um grupo de
pessoas possa completar toda a atividade e as
sub-atividades associadas.
-
A atividade deve ser totalmente
entendida pelo Gerente do Projeto e pela(s) pessoa(s)
que for(em) designada(s) para criar a EAP. Se você tiver
uma atividade que não foi compreendida pelas pessoas
encarregadas, então ela deverá ser fragmentada ainda
mais em sub-atividades para fornecer mais clareza.
-
Em geral, o trabalho deve ser
fragmentado até um nível que possibilite o controle do
Gerente do Projeto. Teoricamente, a EAP poderia ser
fragmentada até que cada atividade fosse de uma ou duas
horas. Obviamente, isto não faz sentido. O membro da
equipe designado a esta atividade não necessita do
trabalho detalhado a este nível e o gerente do projeto
não necessita gerenciar o trabalho a este nível.
Não torne
a EAP demasiada alta
(2.1.6.P6)
Se você
estiver visualizando uma estrutura da EAP sendo construída
com as páginas adesivas na parede, é importante que você não
deixe o número dos níveis ficar alto em demasiado. Dependendo de sua
abordagem para criar a EAP, pode ser que você leve de um a três
níveis para que as entregas sejam definidas. A regra comum é
que o nível das atividades não deve passar de cinco. Os
projetos menores não necessitam mais que dois ou três
níveis de atividades para cada entrega. Se você tiver um
projeto muito grande, os níveis podem ser maiores.
Entretanto, há um ponto onde os detalhes se tornam
demasiadamente complexo para serem gerenciados. Se você
achar que está definindo cinco ou mais níveis de
atividades, pare e avalie o que você está fazendo.
Primeiramente, você pode estar definindo o trabalho em um
nível demasiadamente baixo. Segundo, você pode ter definido
sua entrega em demasiado. Neste caso, veja se uma entrega
grande pode ser fracionada em partes menores e integrada. O
trabalho associado com as entregas menores não deve exigir
tantos níveis.
Dicionário de
Estrutura Analítica do Projeto
(EAP)
(2.1.6.P8)
Se a
EAP for muito grande, pode fazer sentido posicionar todas as informações
importantes dentro de um dicionário de dados. O Dicionário ajudara a
controlar todas as atividades sumárias e detalhadas, como, fornecer uma
curta descrição, um numero de identificação (1.1, 1.1.1, 1.1.2, etc.) e
uma estimativa de esforço para cada atividade. Normalmente, o dicionário
não é necessário, mas se a sua EAP tiver centenas (ou milhares) de
atividades detalhadas, pode haver muito para controlar manualmente.
Quando a informação da EAP for introduzida numa ferramenta, a ferramenta
poderá ajudar a manter as mudanças sobre o trabalho para que você saiba
como as mudanças afetarão a EAP e o cronograma. Possuir a EAP dentro de
uma ferramenta facilita a informação para re-usar em futuros projetos.
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.
A Relação
entre a Definição e o Planejamento do Trabalho
(2.0.P2)
Você
vai notar que no processo TenStep existem as step 1 de definir e step 2
planejar. Isto não significa que você precisa seguir uma ordem
seqüencial de processos. Muitas vezes você vai se encontrar na situação
de não poder completar a Definição do Projeto antes de começar a
construir o plano de trabalho (Workplan). Em muitos casos, estes dois
tipos de deliverables (resultados esperados), precisam ser desenvolvidos
paralelamente. Assim que você começar a coletar informações sobre Escopo
e Deliverables, você necessitara para começar para leiautar uma
linha-de-tempo para obter informações de duração ou tempo, e empenho.
Quando você obtiver mais informações sobre a definição do projeto, você
adicionara mais detalhes em seu plano de trabalho (Workplan). Também,
quando os deliverables, o escopo, as suposições e a abordagem estiverem
completas, você devera ter informações suficientes em seu plano de
trabalho (Workplan) para estimar o capital (orçamento), o empenho, e o
tempo necessário para então completar a Definição do Projeto.
Utilize Planos de
Trabalho (Workplans) Anteriores e Semelhantes e Também Modelos de Planos
de Trabalho (Workplans) Pré-Criados
(2.2.P1)
Você pode sempre
utilizar a técnica de Estrutura Analítica do Projeto (EAP) para criar um
Plano de Trabalho, a partir do nada. Mas, a EAP não é sempre a maneira
mais eficiente para criar um plano de trabalho (Workplan). A melhor
maneira para construir um plano de trabalho (Workplan) é utilizar
novamente aquilo que foi previamente criado. Por exemplo, se um projeto
semelhante ao seu já foi concluído no passado, inicie utilizando aquele
plano de trabalho (Workplan) como base e modifique-o conforme as suas
necessidades. Isto economizará todo o esforço associado com o
'descobrimento' de como o trabalho deverá ser esboçado. Isto é
especialmente válido se o Gerente de Projeto anterior manteve seu plano
de trabalho (Workplan) atualizado. Então você terá o plano de trabalho (Workplan)
atual que foi utilizado para executar um trabalho semelhante.
Se você não tiver um
plano de trabalho (Workplan) anterior de um projeto similar, investigue
se há na sua empresa, modelos pré-criados de planos de trabalho (Workplans)
para projetos com determinadas características. Por exemplo, a sua
empresa pode ter modelos (templates) pré-criados para implantar um
pacote de software, ou desenvolver uma aplicação de software, etc. Neste
caso, veja se a abordagem que você está utilizando em seu projeto
combina com algum destes templates. Se a reposta for positiva, o
template poderá ser utilizado como um ponto de partida. Depois de
determinar qual o template combina, você deverá avaliar as atividades do
template e determinar quais são aplicáveis ao seu projeto. As atividades
aplicáveis devem permanecer no seu plano de trabalho (Workplan) e as
atividades que não forem necessários serão descartadas.
