|
1. |
Flexível e Escalável -
Um processo de Gerenciamento de Projetos tem que ser flexível e
escalável baseado no tamanho do projeto em questão. A TenStep se
refere ao conceito de "pequenas metodologias para projetos
pequenos, grandes metodologias para projetos grandes". (Escalabilidade refere-se ao nível de complexidade do processo de gerenciamento
de projetos ao tempo e ao foco aplicado aos projetos) |
|
2. |
Aplicável a todos os tipos de projetos
- A
Metodologia TenStep Processo de Gerenciamento de
Projetos® foi
projetada para ser aplicada a todos os tipos de projetos, desde
a construção de uma casa, ou mesmo um circuito eletrônico, ou um
software. O processo da Metodologia TenStep também é compatível
com todos os tipos de metodologias utilizadas no ciclo de vida
dos projetos (waterfall, Rápid Application Development (RAD),
Agile, etc...). Todos os projetos apresentam necessidades em
comum para gerenciar o escopo, os riscos, os problemas, a
qualidade, etc... |
|
3. |
Gerenciamento Pró-ativo -
Os Projetos devem ser gerenciados pró-ativamente não importando
o tamanho do projeto. Gerentes de Projetos que esperam as coisas
acontecerem quase sempre se encontram com problemas.
|
|
4. |
Desenvolver parceria entre a equipe do projeto e o cliente
- Um projeto bem-sucedido normalmente requer parceria entre a equipe do
projeto e o cliente. Geralmente, os projetos corem um grande risco de
fracassar sem a participação ativa do cliente. |
|
5. |
Estabelecer os processos de gerenciamento de projetos no
começo do projeto -
Os processos de gerenciamento de projetos devem ser
estabelecidos no começo dos trabalhos, e entendido pela equipe
envolvida no projeto e pelo cliente. A maioria dos processos
requer o envolvimento de múltiplos membros por parte do cliente
e da equipe do projeto. |
|
6. |
Os
gerentes de projetos
devem
ter um nível suficiente de autoridade
- Os gerentes de projetos necessitam ter um nível
suficiente de autoridade para obter sucesso em seus projetos. Se
o gerente de projetos for o responsável pela entrega do projeto,
e o mesmo não puder tomar decisões importantes e necessárias
para gerenciar o projeto, então o projeto provavelmente não terá
êxito. |
A Metodologia
TenStep PGP
®
Não Inclui
os Processos Associados ao Ciclo de Vida do Projeto
(0.4.P2)
Uma metodologia de gerenciamento de
projetos é tipo um guarda-chuva, onde abaixo está o restante do trabalho
do projeto a ser executado. Lembre-se, que o gerenciamento de projetos é
o que facilita o sucesso do projeto e não o projeto em si. O trabalho do
projeto é referido como "ciclo de vida". Não importa o tipo de trabalho,
tipicamente o ciclo de vida segue um processo que inclui; análise,
design, construção, teste e implantação (ou um de muitos outros ciclos
de vida do projeto). Os processos relacionados ao ciclo de vida do
projeto estão fora do escopo da metodologia TenStep PGP®.
(o ciclo de vida é explicado em detalhe no produto
LifecycleStep™)
Esta
metodologia de Gerenciamento de Projeto é como se fosse um guarda-chuva,
onde abaixo dele está sendo executado o restante do trabalho do projeto.
Lembre-se de que Gerenciamento de Projetos é a ferramenta para facilitar
o sucesso do projeto e não é o projeto em si. Não importa o tipo de
trabalho, tipicamente todos seguem um ciclo de vida que inclui, análise
de requerimentos do negócio, design, construção, teste, e implantação.
Mais uma vez, reconhecendo a importância do entendimento do processo
necessário para produzir as entregas do projeto, esta área está fora do
escopo do processo da metodologia
TenStep. (Os processos do ciclo de vida do projeto são explicados em
detalhes no produto
LifecycleStep™).
A Metodologia TenStep PGP®
Não
Inclui
a Coleta das Exigências Detalhadas
(0.4.P3)
A
lgumas
metodologias incluem a coleta das exigências do negócio como parte do
processo de gerenciamento de projetos. A metodologia TenStep PGP®
inclui análise em um nível elevado suficiente de modo que o documento
"Termo de abertura do projeto" (Termo
de abertura do projeto)
possa ser preparado. A fase formal de análise/exigências
do negócio
é considerada parte do ciclo de vida do projeto e então está fora do
escopo da metodologia TenStep PGP®.
(Para maiores detalhes sobre o fase de análise, veja
o produto
LifecycleStep™.)
Há uma preocupação entre
muitos gerentes de projetos, devido há expectativa de entregar ao
cliente uma estimativa detalhada junto com o documento "Termo de
Abertura do Projeto" e o cronograma associado. Entretanto, nesse ponto
do projeto as exigências detalhadas ainda não foram coletadas, então,
como você poderá fornecer uma estimativa detalhada? Esta questão parece
válida. Ainda, quando falamos sobre a coleta de exigências detalhadas,
geralmente nós estamos falando sobre a fase de análise que faz parte do
ciclo de vida do projeto, e não do trabalho inicial (definição e
planejamento) associado ao gerenciamento do projeto.
Seu primeiro pensamento
pode ser que, talvez você deva ter as exigências detalhadas antes de se
comprometer a fornecer uma estimativa sobre o trabalho. Entretanto, isso
realmente é prático? Por exemplo, em um projeto típico de
desenvolvimento de software, o projeto pode durar seis meses e o
processo de coleta das exigências poderá durar de seis a oito semanas
(ou mais). Então, nós devemos realmente esperar até que as exigências
estejam coletadas e aprovadas para fornecer uma estimativa? Caso sim, o
projeto poderá ser completado um terço antes de nós validarmos os custos
e o prazo final do projeto. Se o projeto não fizer mais sentido baseado
em uma perspectiva de custos e benefícios, você poderá já ter gasto uma
quantidade significativa de dinheiro. Aí já é muito tarde para saber, e
é a principal razão da maioria das metodologias em gerenciamento de
projetos não incluírem o processo de coleta das exigências detalhada.
Também se você usasse este
mesmo argumento, você poderia dizer que ainda não tem confiança em
estimar o trabalho sem primeiramente concluir a fase de design, e então
você ainda não tem confiança em estimar o trabalho sem concluir a fase
de construção, etc.. Você vê que esta mesma lógica pode ser utilizada ao
extremo.
As seguintes abordagens
permitirão estimar o trabalho antes de coletar as exigências detalhadas.
(estas abordagens supõem que a coleta das exigências faz parte da fase
de analise do projeto. Se você usar técnicas ágeis ou iterativas, você
poderá coletar as exigências de uma maneira iterativa durante todo o
projeto.)
-
Criar uma estimativa
com variação de
±10%
baseado no documento
"Termo de Abertura do projeto" e o cronograma.
Esta é a abordagem
tradicional, e em muitos ou na maioria dos casos, ainda é viável.
Entretanto, há uma suposição subjacente que o gerente do projeto
e/ou a equipe do projeto façam esse tipo de trabalho antes, e
conseqüentemente poderão estimar o trabalho dentro de uma variação
de ±10%
baseado nas exigências em um nível elevado que foram coletadas
durante a definição do projeto. Se você descobrir que estimou
incorretamente depois que as exigências foram coletadas, você terá
que levantar uma bandeira e levar a informação ao patrocinador para
resolução. No final de cada fase do projeto, você deverá fazer uma
verificação da estimativa e comunicar as variações ao patrocinador.
-
Fracione o trabalho
em partes menores. Se você não se sentir confortável para
fornecer uma estimativa do projeto com uma variação de
±10%,
então fracione o projeto em projetos menores. Quando você usa essa
técnica, você poderá criar um projeto para coletar as exigências.
Neste caso, você deverá poder criar uma estimativa para este pequeno
projeto com uma variação de
±10%.
Depois que este projeto de coletar as exigências estiver concluído,
você poderá usar a informação para criar um segundo projeto para
executar o restante do trabalho. Baseado na informação fornecida
pelo primeiro projeto, você deverá poder criar uma estimativa para o
restante do trabalho com a variação de
±10%.
Quando isso for feito, as entregas finais terão sido criadas através
de dois projetos. Cada um desses projetos foi estimado e gerenciado
dentro de
±10%
do orçamento e do cronograma.
-
Primeiramente, criar
uma estimativa grosseira do prazo e do orçamento e ajustá-las
apropriadamente após a coleta das exigências. Esta é uma
variação da primeira abordagem acima. Nesta abordagem, o gerente do
projeto fornece uma estimativa "grosseira" do trabalho ao mesmo
tempo em que a definição do projeto e o cronograma são criados. O
gerente do projeto não tem compromisso de entregar o projeto dentro
desta estimativa "grosseira" (ao contrário da primeira opção acima).
Depois que as exigências forem coletadas e avaliadas, o gerente do
projeto poderá fornecer uma estimativa mais detalhada e com uma
variação de
±10%.
Esta estimativa mais detalhada, será o número que o gerente do
projeto se comprometerá a entregar o projeto.
Muitos gerentes de projeto
pensam que a melhor abordagem é coletar as exigências de forma
iterativa. Entretanto, esta abordagem iterativa não
fornece a resposta nos
termos de como você poderá estimar o projeto com uma variação de
±10%.
De fato, as
abordagens iterativas poderão tornar este nível da exatidão mais difícil. As três soluções acima fornecem um
grupo
mais viável das técnicas para estimar o trabalho com um nível de
exatidão de
±10%. Para maiores informações sobre estimativas, veja
a seção
2.1.1
Construir o Cronograma e o Orçamento / Processo /
Estimativa
e a seção
2.2.1
Construir o Cronograma e o Orçamento / Técnicas / Técnicas de Estimação
.
O Processo de Aquisição é Importante
em Alguns Projetos, Mas Não é Um "Passo Separado"
(0.4.P4)
Algumas metodologias incluem o trabalho
relacionado a vendedores e os contratos como uma parte chave do processo
de gerenciamento de projetos. Na metodologia TenStep PGP®, o processo de
aquisição é importante, mas não é tão importante quanto os outros
processos definidos na metodologia. Em projetos maiores, o gerente do
projeto necessita compreender mais profundo o processo de aquisição e o
gerenciamento de vendedores. Entretanto, a maioria das empresas tem
departamentos especializados na área de compras e jurídicas que
normalmente tem responsabilidade principal pelo gerenciamento dos
vendedores.
Também, a responsabilidade do processo de
aquisição e do gerenciamento dos vendedores dependente da sua empresa e
do setor de indústria. Por exemplo, Os gerentes de projetos da área de
TI tendem a ter menos responsabilidade nestas áreas, enquanto que os
gerentes de projetos do setor de construção civil, podem ter a
responsabilidade total.
A
metodologia TenStep PGP® contém informação sobre o gerenciamento de
aquisições numa extensão separada, que pode ser integrado na metodologia
TenStep PGP®. Esta extensão é opcional e pode ser utilizada se for útil
para sua organização. Para maiores informações sobre o gerenciamento de
aquisições, veja a seção
Extensão - Aquisições.
A Metodologia
TenStep PGP®
Não Inclui
o Processo de Obtenção de Capital e Recursos Humanos para o Projeto
(0.4.P5)
Para a
aplicação da metodologia TenStep PGP®, se assume que o capital e os
recursos humanos
necessários para o projeto já foram aprovados. Todas as organizações
possuem alguns processos que são utilizados para a elaboração de idéias,
priorização das mesmas e para fornecer o capital necessário. A
metodologia TenStep PGP®
não inclui estes processos e não considera os mesmos
como uma parte do processo de gerenciamento de projetos. Os processos
relacionados ao metodologia TenStep PGP®
começam quando o projeto
é
definido formalmente e o gerente do projeto foi designado ou contratado.
Assume-se que os processos de justificativa e a aprovação do capital e
dos recursos humanos já foram concluídos.
Na Metodologia TenStep PGP®,
o
Projeto
Começa
Oficialmente Quando o Gerente do Projeto é Contratado ou
Designado, ou Quando o documento "Termo de abertura do projeto" e o Cronograma
já foram criados (0.4.P6)
Para a
aplicação da metodologia TenStep PGP®,
o
projeto começa oficialmente quando o gerente do projeto é contratado ou
designado.
Tipicamente, o primeiro trabalho do gerente do projeto é
definir formalmente o trabalho do projeto através de um documento de "Termo
de abertura
do projeto",
e construir o Cronograma e Orçamento. Mas, esta definição do começo
do projeto continua sendo válida mesmo se o Gerente do Projeto
oficial não
foi envolvido na criação do documentos (todos os documentos poderão ter sido completados
antes). Lembre-se de que o gerenciamento de projetos é uma função. Qualquer
pessoa que criar o documento "Termo de abertura do projeto" (Termo de
abertura do projeto)
e o
Cronograma
e Orçamento está fazendo a função de Gerente do Projeto, mesmo se outra
pessoa for designada para o cargo mais tarde.
O gerente
do projeto tem a autoridade e a responsabilidade (0.4.P7)
A metodologia PGP® supõe que o gerente do projeto tem um grau de
responsabilidade e de autoridade no projeto. Eles não têm
necessariamente o controle total, mas têm algum nível de autoridade. Se
a sua organização tem gerentes de projetos com o nível de autoridade
muito pequeno, provavelmente eles são coordenadores de projetos. Na
metodologia Tenstep PGP®, o gerente do projeto deve tem uma autoridade
apropriada.
Reconheça a
finalidade do Business Case e do Termo de Abertura do Projeto
(0.4.P8)
Na metodologia TenStep PGP®, o Business Case é usado para
justificar um projeto (em uma perspectiva do negócio) e alocar o
financiamento para o mesmo. Entretanto, mesmo que o Business Case
tenha sido aprovado, isto não significa que o projeto está pronto para
começar. É possível que se passem alguns meses antes que o projeto
comece realmente.
O projeto começa oficialmente quando o gerente do projeto é atribuído. A
primeira coisa que o gerente do projeto deve fazer é definir o trabalho
do projeto e criar o cronograma e o orçamento. O Business Case é
utilizado como uma entrada. Este trabalho resulta no documento Termo de
Abertura do Projeto, e na criação de um cronograma e no orçamento do
projeto. Quando o Termo de Abertura do Projeto for aprovado, o projeto
estará pronto para começar. (Isto contrasta com Guia PMBOK® do PMI, onde
o Termo de Abertura do Projeto autoriza o projeto. Na metodologia
TenStep PGP®, o projeto é autorizado quando o Business Case é
aprovado, e o projeto está pronto para começar quando o Termo de
Abertura do Projeto é aprovado.)
O modelo
TenStep é Focado Mais nos Projetos Internos
(0.4.P9)
A abordagem por trás do modelo TenStep supõe que você tem um projeto
interno com clientes internos. Quando a maioria dos processos for
igualmente aplicável aos projetos do tipo cliente-vendedor,
algumas áreas do modelo deverão ser revisadas. Por exemplo, em um
projeto onde tenha um cliente externo, poderá ser necessário utilizar o
documento Declaração de Trabalho em vez de um Termo de Abertura do
Projeto. Também, poderão ter algumas expectativas muito mais severas ou
menos flexíveis em termos de prazos, orçamento e recursos. Papéis,
funções e responsabilidades também poderão ser diferentes.
O
Papel do Patrocinador é Muito Importante (0.4.P10)
A metodologia TenStep PGP® identifica o papel do patrocinador como um
ator chave no sucesso do projeto. Muitas organizações têm uma pessoa
neste papel, mas podem ser chamadas por nomes diferentes, tais como o
Campeão do Projeto ou o Cliente. A metodologia TenStep PGP® confia neste
papel para obter e manter o financiamento para do projeto, aprovar as
entregas principais, eliminar obstruções, e geralmente assegura-se de
que o projeto tenha o suporte e apoio necessário para ser bem-sucedido.
Entretanto, algumas organizações não têm este tipo de papel do
patrocinador. Em algumas organizações, o patrocinador não é envolvido
diretamente no projeto, nesse caso, uma pessoa intermediária é atribuída
para representar os interesses do cliente. Em alguns projetos, o papel
do patrocinador poderá não existir. Entretanto, na metodologia TenStep
PGP® alguém deve assumir este papel. Se um patrocinador não existir ou
não puder ser identificado, o gerente do projeto deverá procurar uma
pessoa que possa preencher este papel.
