Livraria Virtual PMI

2007 Project Management Institute

Gerenciamento de Programas superando

obstculos para o sucesso
Experincias da vida real podem contribuir para um melhor entendimento
de como os programas podem ser usados de forma bem sucedida
Por Diane Haubner, PMP

Resumo
O Gerenciamento de Programas formal est se tornando uma iniciativa mais difundida para
ajudar a melhorar processos de gerenciamento de projetos simultneos. Embora o
gerenciamento de mltiplos projetos por um mesmo dispositivo j uma prtica antiga, o
gerenciamento de programas tornou-se mais reconhecido pela consistncia eficaz que traz ao
processo. O reconhecimento de tal mtodo, oficialmente, como um processo estruturado,
fornece aos gerentes de projeto e programas um conjunto de normas e controles que
contribuem para o sucesso.
Este artigo no sobre o que gerenciamento de programas. A autoria publicada desse
processo est documentada no O Padro para Gerenciamento de Programas do PMI (The
Standard for Program Management). Este artigo , por sua vez, um texto sobre experincias
reais que podem contribuir para uma melhor compreenso de como programas podem ser
gerenciados com sucesso. Enquanto este artigo sugere que escritrios formais de programas
com boa comunicao e monitoramento de processos ajudam a evitar os desafios
normalmente encontrados, ele tambm pretende descrever os desafios mais comuns e
solues apropriadas que geralmente existem em uma organizao sem um forte controle de
escritrio de programas.

Os programas so compostos por

vrios projetos individuais, cada um com
um gerente e uma equipe que
responsvel pela entrega de um produto
seguindo os padres de gerenciamento
de projetos. Os projetos so agrupados
em um programa porque uma
organizao percebe que cada um dos
projetos existe para alcanar o mesmo

objetivo estratgico em benefcios

organizacionais no geral.
Todos e quaisquer projetos que
fazem parte de um programa podem ser
muito bem sucedidos individualmente e
dentro do programa. No entanto, o
programa, como um todo, pode falhar.
O motivo mais recorrente para essa
falha no ver o programa como um
projeto em si e no construir um forte

PMI Virtual Library | www.PMI.org | 2007 Project Management Institute


processo de integrao de cada um dos
sub-projetos dentro do programa.
muito fcil combinar vrios
projetos em um nico cronograma,
identificar as dependncias cruzadas de
projetos, gerenciar esse nico
cronograma como o cronograma do
programa, e ainda falhar. Isso porque um
programa no simplesmente um
conjunto de projetos que so
combinados para um nico objetivo. Um
programa desafiador pelo fato de que
cada um dos projetos independentes so
geralmente vistos e gerenciados como
tal - individualmente.
Este ponto de vista "individual" dos
projetos um fenmeno natural. Cada
gerente de projeto responsvel por
assegurar a entrega para a qual ele ou
ela atribudo. Geralmente, existe
pouco interesse ou tempo gasto na
preocupao com outros projetos do
programa. Isso acontece no porque
cada gerente de projeto no
consciente ou atento aos outros
projetos. Na maioria dos casos,
simplesmente porque o gerenciamento
do programa no foi suficientemente
formalizado, documentado e comunicado
s equipes de projetos para permitir que
cada equipe entendesse como elas se
encaixam no programa global.
Relacionando Gerenciamento de
Projetos com Gerenciamento de
Programas Os processos do Um Guia de
Conhecimento em Gerenciamento de
Projetos (Guia PMBOK) foram,
historicamente, bem aplicados em
projetos. Os programas e as suas
respectivas equipes de gerenciamento,
por outro lado, geralmente sofrem pela

falta dos mesmos processos. As equipes

de projetos so frequentemente
consideradas como unidades
administrativas funcionais, guardies ou
auditores. Estas equipes geralmente no
so consideradas como tendo os tipos
detalhados de estruturas e processos no
lugar, como os projetos tm. Elas so
geralmente vistas como gerentes de
gesto e no de produo.
O Padro para Gerenciamento de
Programas do PMI descreve como essas
hipteses no so o caso anteriormente
discutido. Ele explica os programas
como tendo trs temas - gerenciamento
de benefcios, gerenciamento das partes
interessadas e governana de programasque so experincias implcitas para o
objetivo desse texto. Os dois primeiros
temas so geralmente mais fceis de
atingir e frequentemente seguem
processos para gerenciamento de
benefcios e das partes interessadas de
uma forma semelhante forma como os
projetos gerenciam esses processos. A
governana de programas, no entanto,
geralmente torna-se um desafio, devido
tendncia dos projetos separados
preferirem governarem a si mesmos.
Eles tornam-se particularmente mais
difceis de serem gerenciados quando se
trata dos processos de conhecimento
nas reas de Gerenciamento dos
Recursos Humanos, Gerenciamento da
Qualidade, Gerenciamento das
Comunicaes e Gerenciamento dos
Riscos .
Enquanto vrias, se no todas, das
nove reas de conhecimento de
gerenciamento de projetos so aplicveis
ao gerenciamento de programas, este
artigo concentra-se nos princpios e
tcnicas relevantes para as quatro reas
especficas de conhecimento citadas
acima, como elas lidam com o
gerenciamento de programas
aperfeioado e especificamente em
relao governana de programas.

PMI Virtual Library | www.PMI.org | 2007 Project Management Institute

Dentro de uma empresa , normalmente, difcil para os

funcionrios dedicarem seu tempo a um projeto, mesmo se designados
em tempo integral, pois difcil no se desviar por "trabalhos do dia a
dia." Dentro de um programa, ainda mais complicado quando um
mesmo indivduo requerido para trabalhar em vrios projetos ao
mesmo tempo.

Gerenciamento dos Recursos

Humanos Desafios e Solues
Um dos maiores desafios para o
gerenciamento de programas o
gerenciamento dos recursos. Este
desafio est geralmente relacionado ao
gerenciamento do tempo, relaes
hierrquicas e interao de equipe.
Dentro de uma empresa ,
normalmente, difcil para os funcionrios
dedicarem seu tempo a um projeto,
mesmo se designados em tempo integral,
pois difcil no se desviar por
"trabalhos do dia a dia." Dentro de um
programa, ainda mais complicado
quando um mesmo indivduo
requerido para trabalhar em vrios
projetos ao mesmo tempo. Por
exemplo, uma organizao pode ter
apenas um administrador de banco de
dados, ou um responsvel pela
segurana, um especialista em controle
de mudana, um gerente de
departamento, etc. E enquanto esses
indivduos podem, frequentemente, dar
suporte mais facilmente organizao ao
mesmo tempo em que eles executam
tarefas relacionadas ao projeto, torna-se
extremamente difcil conciliar tais
funes, quando eles so designados
como participantes de igual importncia
em vrios projetos dentro do programa,
todos concorrendo pela contribuio
individual.
Em segundo lugar, os membros da
equipe, organizacionalmente, possuem
relaes hierrquicas que podem ter
vrios supervisores, incluindo gerentes
de projetos e membros da equipe de

gerenciamento organizacional que tm

seus prprios interesses departamentais
a considerar. As relaes cruzadas e os
impactos de equipes de mltiplos
projetos concorrendo e/ou competindo
pela ateno e adeso da gerncia
tornam-se mais complexas.
Terceiro, as interaes entre
equipes so geralmente mais
desafiadoras. As equipes de projetos
dentro dos programas tendem a se isolar
s vezes. Elas fazem isso para "proteger
seu territrio" dos controles gerais do
programa. Elas tambm o fazem para
formarem relaes mais prximas
dentro da equipe que so simplesmente
mais fceis de gerenciar do que as
relaes cruzadas com outras equipes de
projeto. Geralmente, outras equipes de
projeto tm objetivos, produtos, prazos,
oramentos e ateno completamente
diferentes do que outra equipe do
projeto. Isso geralmente leva a essa
postura isolacionista.
Torna-se necessrio, ento, no nvel
de um programa, prestar maior ateno
aos ativos de processos dos Recursos
Humanos que formam o plano do
programa. Essas aes ajudaro a trazer
sucesso:

A formalizao e validao de
organogramas do projeto de forma
individual, como parte do organograma
global do programa, importante. Esta
representao organizacional tambm
precisa incluir equipes de gerenciamento
e entidades externas.

PMI Virtual Library | www.PMI.org | 2007 Project Management Institute

A criao de descries
detalhadas de cargos que descrevem as
atividades do programa, bem como as do
projeto, precisam ser includas. Os
cargos devem ser descritos de uma
forma que permita ao indivduo
compreender que seu papel e
compromisso podem ser diferentes
dependendo da forma que eles
interagem dentro dos vrios projetos.

Criao de um grfico de
responsabilidades (RACI) que inclua a
dimenso do programa em alinhamento
com a responsabilidade do projeto. Um
exemplo mostrado na figura 1.

Regras bsicas precisam ser

documentadas em nvel de programa e
se tornarem parte do processo de
reviso de qualidade do ponto de vista
de ativo organizacional. Uma boa
maneira de assegurar a uniformidade
nesta tcnica prover o programa com
um processo organizacional de tempo
integral ou mudar o gerenciamento de
recursos. Este papel fundamental no
somente no gerenciamento de recursos,
mas em termos de comunicao dentro
e fora das equipes do programa.

O processo/mudana
organizacional de gerenciamento dos
recurso tambm pode ser importante
para garantir que as equipes se
encontrem e se acolham numa base
regular, atravs de atividades planejadas,
tanto profissional como pessoalmente.
Um programa de recompensas, como
parte desse processo tambm eficaz,
uma vez que cada membro da equipe
est ciente de como o programa
funciona e quais os comportamentos e
resultados so esperados.

A comunicao antecipada e
repetida das expectativas do nvel do
programa e a relao com os benefcios
do projeto crucial. Cada membro da
equipe deve ser constantemente
lembrado de que eles so parte de um
esforo organizacional maior.

O mapeamento completamente
documentado de pessoas e de seus
rendimentos para as realizaes dos
benefcios do projeto/ programa devem
ser compartilhados. Os recursos do
programa precisam participar de
reunies do programa ou eventos para
ajudar ainda mais esse objetivo. Essas
reunies no devem ser limitadas apenas
aos gerentes de projeto, mas devem
incluir todos os nveis de participantes
do projeto quando benfico.

Figura 1: Diagrama de
RACI do
Programa/Projeto. R= responsvel pela execuo; A=responsvel pela aprovao; C=
consultado; I=informado
PMI Virtual Library | www.PMI.org | 2007 Project Management Institute


Gerenciamento da Qualidade
desafios e solues
As equipes de projeto,
especialmente na entrega de produtos
diferentes utilizando diferentes
ferramentas, geralmente, consideram-se
livres para ignorar as diretrizes ou regras
do programa. A postura isolacionista
descrita sob os desafios do
gerenciamento dos recursos humanos,
geralmente, contribui para essa viso. Em
muitos casos, as equipes de projeto,
especialmente se compostas de
fornecedores terceirizados, ficam
bastante confortveis com a sua prpria
maneira de executar um projeto e no
tm interesse em concordar com o
"modo do programa". Equipes que
possuem uma histria juntos, seja
atuando em grupos dentro da
organizao ou como equipes de
produto, se veem como especialistas em
seus prprios processos. Embora tudo
isso possa ser verdade, quando vistos de
uma perspectiva do programa, a entrega
e a qualidade do processo podem estar
em risco.
Os padres de qualidade,
especialmente quando relacionados a
processos do projeto e entregas,
precisam ser mais altamente
padronizados nos programas.
Reconhecendo que todos os projetos
contribuem para as expectativas de
benefcios gerais do programa, os
padres de qualidade precisam ser
consistentes atravs dos projetos para
que esses benefcios possam ser
igualmente entregues. Entregas que
parecem diferentes podem gerar
confuso para o usurio final. Processos
tais como testes, manuais de usurios,
etc., que so desenvolvidos com
modelos, abordagem, contedo e estilo
diferentes criam nveis diferentes de
qualidade.
Para garantir sucesso, os padres de
qualidade devem ser projetadas e
documentadas em um nvel

suficientemente elevado de modo que

elas possam ser facilmente mapeadas
para as entregas e processos que
contribuem para os benefcios
esperados. Um plano de qualidade do
programa deve ser escrito durante o
processo de iniciao do programa que
identifica quais os padres de qualidade
que sero adotados, como eles sero
aplicados e monitorados e como eles se
conectam com os benefcios esperados.
Este plano deve servir como entrada
para cada atividades do Grupo de
Processos de Planejamento do Projeto
(ver Figura 2).
Alm do plano de qualidade, ,
geralmente conveniente, configurar uma
biblioteca de modelos e descries de
processos que so projetados de tal
modo, que eles possam ser usados por
qualquer equipe de projeto sem ter de
redesenhar a ferramenta. Por exemplo,
um modelo de plano de teste que define
os processos de teste esperados a serem
aplicados a todos os projetos e como
estes processos de testes so
entrelaados aos testes de programa,
pode ser criado. O uso de padres,
modelos, instrues, recursos, softwares
e outros componentes deve ser
considerado.
A biblioteca deve, tambm, servir
como repositrio do programa para
todo o trabalho em progresso e
resultados finais. Ela deve ser organizada
de forma que permita que tanto a
documentao especfica do projeto,
como as normas de nvel do programa
sejam facilmente acessadas, armazenadas
e empregadas. A Figura 3 mostra um
nico exemplo de como uma biblioteca
desse tipo pode ser projetada. Esta
abordagem assume uma estrutura de
alto nvel baseada no programa global.
Dentro do Grupo de Processos de
Execuo, cada projeto tem seu
conjunto individual de documentos e
entregas de projeto.

PMI Virtual Library | www.PMI.org | 2007 Project Management Institute

Figura 2: Conectando a qualidade entre os objetivos da organizao, programa e

projeto.

Gerenciamento das
Comunicaes desafios e
solues
Geralmente, no prestada a
ateno requerida s comunicaes do
projeto visto que a maioria das equipes
de projeto se concentram em finalizar,
primeiramente, a "lista de tarefas". A
comunicao, portanto, tende a ser
centrada em torno de reunies de
equipe, atualizaes do comit de
direo e boletins informativos
ocasionais. Enquanto que isso uma
abordagem tipicamente limitante para as
comunicaes, ela tambm est presente
em um nvel do programa, quando vrios
projetos dentro do programa no
somente funcionam dessa maneira, mas
ainda excluem outros participantes do
programa desses processos. Esta
comunicao est relacionada no
apenas comunicao das partes
interessadas, mas comunicao do
programa/projeto relacionada a
questes, status e outras comunicaes.

As equipes de projeto tendem a

documentar suas prprias reunies, criar
suas listas de questes e enviar e-mails
para seus prprios membros. Essas
atividades tm um lugar. Mas, fora dessa
abordagem, est a necessidade de
compreender e comunicar como uma
simples questo em uma equipe pode
afetar outra equipe . Ou como uma
necessidade de um recurso em uma
equipe visto como algo normal, sem se
comunicar com outras equipes caso
exista conflitos de agendamento para
esse mesmo recurso.
Em alguns casos, comunicaes
pblicas em boletins informativos, sites
da empresa, folhetos de propaganda,
mensagens transmitidas em rdio e em
outros lugares, s vezes podem impactar
negativamente outro projeto dentro do
programa sem que os iniciadores
percebam. Uma comunicao, em
particular, pode enviar uma mensagem
exatamente oposta a que uma equipe
diferente est tentando passar, criando
confuso para o leitor.

PMI Virtual Library | www.PMI.org | 2007 Project Management Institute

Figura 3: Exemplo de uma biblioteca de documentos de um projeto em um programa.

Do ponto de vista do programa, as
comunicaes devem ser
deliberadamente formalizadas e
reconhecidas como a nica fonte de
mensagens chave. A uma pessoa
especfica da equipe do programa deve
ser atribudo um papel de comunicao.
Esse indivduo precisa desenvolver o
plano de comunicao partir de uma
perspectiva do programa e incluir
comunicaes especficas de projeto
dentro desse plano.
O plano de comunicao do
programa precisa ser projetado para
posteriormente concentrar-se na
comunicao relacionada com os
benefcios originais do programa. Ele
precisa estrategicamente relacionar as
contribuies de cada projeto e seus
status de uma maneira a comunicar
todos os benefcios para todas as partes
interessadas. Esta forma de abordagem
permite que o ouvinte ou o leitor capte
uma mensagem de forma consistente.
Alm disso, essas mensagens devem ser
enviadas com tom, estilo e linguagem
consistente para que o ouvinte
reconhea-as facilmente ao longo do

tempo. Isso contribuir para menos

confuso e interpretao errnea por
parte do ouvinte.
O programa de comunicao focado
tende, posteriormente, a ser percebido
como mais "oficial" dentro das
organizaes. Essas comunicaes so,
geralmente, associadas a um escritrio
formal de comunicaes da organizao,
o que contribui para uma posio, em
geral, mais proeminente. Usando
efetivamente essa vantagem, no entanto,
significa que o principal as comunicaes
do programa devem trabalhar
intimamente com cada uma das equipes
de projeto para compreender
completamente o seu papel, seus
objetivos e seus resultados. Isso
permitir que cada uma das equipes de
projeto tenham sucesso ao comunicar o
que necessrio sem se sentirem
deixadas de lado.
Todas as equipes de projeto
precisam ser treinadas a fim de

PMI Virtual Library | www.PMI.org | 2007 Project Management Institute


considerarem as comunicaes como
um ponto crtico e sensvel do processo
ao longo do caminho para a concluso
do projeto. Sesses de orientao das
equipes devem incluir a instruo
especfica de como as comunicaes
ocorrero dentro do programa. Uma
cpia do plano de comunicao do
programa deve ser dado a cada membro
da equipe do projeto `a medida que
seguem com o programa.

Relatrios peridicos de
status (semanal, quinzenal)
devem ser publicados por cada
equipe de projeto utilizando um
formato consistente e
consolidado pela equipe do
programa para ampla
distribuio.
Alm disso, enquanto algumas
comunicaes do programa podem
simplesmente refletir a informao de
apenas um dos projetos dentro do
programa, elas ainda devem ser
compartilhadas com cada um dos
membros das outras equipes do projeto.
Embora seja possvel que muitas pessoas
iro ignorar as comunicaes que elas
no acreditam serem relevantes para o
que foram designadas a fazer, mais
comunicao versus menos, acabar por
reduzir falhas de comunicao no final.
Finalmente, ao passo que para a
maioria das informaes relacionadas ao
projeto cada equipe assumir a sua
prpria responsabilidade de se
comunicar dentro da equipe, os padres
para as comunicaes ainda devem ser
aplicados. Por exemplo, todas as
reunies de equipe devero ter
agendamentos publicados, reunies
publicadas e lista de afazeres. A lista de
participantes reais versus planejados deve
ser includa. As reunies devem ser
publicadas em um site compartilhado do
programa com a inteno de permitir
que qualquer membro do programa

possa participar como "ouvinte".

fundamental aqui que participantes no
relacionados ao projeto compreendam o
seu papel como ouvintes, a fim de tornar
as reunies mais eficientes e no se
atolar em questes no relacionadas.
Por ltimo, relatrios peridicos
(semanal, quinzenal) devem ser
publicados por cada equipe de projeto
utilizando um formato consistente e
consolidado pela equipe do programa
para ampla distribuio. Isso permite que
os membros da equipe se ajustem
rapidamente ao desenvolvimento do
programa sem ter de esperar reunies
ou ler outros resultados.
Gerenciamento dos Riscos
Desafios e Solues
Os riscos do programa podem ter
impactos em todo o programa, incluindo
a programao, qualidade de entregas,
consideraes de design, testes e outras
reas. Riscos do cronograma
normalmente comeam durante o
planejamento do projeto. Em muitos
casos, os projetos dentro de programas,
geralmente, tm cronogramas de incio e
trmino diferentes. Isso,
frequentemente, feito para reduzir o
risco de um "big bang", para distribuir os
recursos de uma forma mais uniforme,
estender o oramento do programa por
um perodo de tempo mais longo e
simplesmente para considerar a durao
real dos projetos de forma individual.
Enquanto essa abordagem faz sentido no
geral, existem riscos associados a ela que
precisam ser cuidadosamente
gerenciados .
Um dos riscos significativos
associados com essa abordagem a
integrao de caractersticas cruzadas ou
de plano de projetos cruzados. Em uma
implementao de sistema, por exemplo,
os projetos separados, cada um com
produtos separados, esto, muitas vezes,
destinados a serem integrados em algum

PMI Virtual Library | www.PMI.org | 2007 Project Management Institute


grau. Por exemplo, um sistema de
servio ao cliente pode integrar uma
informao de faturamento em um
sistema financeiro separado e no
integrado. Decises tomadas dentro de
um de um plano projeto podem ter um
impacto significativo no plano de outro
projeto. Alm disso, se dois projetos
trabalham a partir de cronogramas
diferentes, e mais significativamente, se
um projeto finaliza antes do outro
comear, ento existe um risco
potencial. Apesar de equipes de projetos
separadas dentro de um programa terem
de comunicar seus status entre si atravs
de relatrios do programa ou reunies
do programa, esta forma de
comunicao nem sempre atenua os
riscos de impacto sobre o plano devido
falta de participao das equipes em nvel
de detalhamento.
Outro risco est relacionado com
testes de integrao. Um teste totalmente
completo de integrao de sistemas para
todos os projetos, em um cenrio como
o do exemplo acima, necessrio para
assegurar que todos os componentes
trabalhem em conjunto. Enquanto
eventos de testes de projetos separados
so obrigatrios, os programas
normalmente limitam a integrao
cruzada de projetos s "interfaces".
Como citado acima, quando diferentes
projetos tm diferentes datas de incio,
, frequentemente, impossvel conduzir
o teste de integrao cruzada de
projeto. Enquanto o teste de regresso
, certamente, uma opo a ser usada
para atenuar tal risco, , normalmente,
muito tarde para fazer mudanas de
plano dentro do programa, se as datas
de in;icio j tiverem passado para o
primeiro projeto e se o teste de
regresso mostrou um erro significante
ou mudana de plano.
Os programas, normalmente,
tentam resolver esse risco agendando a
finalizao simultnea de todos os
projetos, mesmo que ainda existam

incios escalonados. O impacto aqui,

contudo, que um deslize em qualquer
um dos vrios projetos ter um impacto
na entrega de todos os outros projetos
dentro do programa. Isso gera,
desnecessariamente, custos e
cronograma excedentes de tempo dos
projetos pontuais.

Riscos Integrados de Planos

Solues que falam sobre os riscos

integrados de planos so tipicamente
ignorados nos programas reais,
simplesmente porque existe uma
percepo de que qualquer alternativa
para o incio e o trmino normais de um
projeto custa mais e leva mais tempo. As
equipes normalmente empregam um
especialista no assunto de cruzamento
de projetos como os "olhos e ouvidos"
para o programa. Contudo, em termos
de atenuao de riscos, uma abordagem
menos comum pode ser realmente mais
barata a longo prazo, e proporcionar
uma validao de resultados mais
completa.
Uma maneira eficaz de planejar
programas para reduo de riscos de
planos usar a abordagem de nico
incio-continuao mltipla. No incio
do programa, todas as equipes de
projetos iniciam ao mesmo tempo. Elas
conduzem sesses de anlises e planos,
processos de validao As-Is, requisitos
tcnicos e funcionais e vises to-be,
simultaneamente. As entregas partir
desse ponto inicial tornam-se, ento,
entradas dentro de um programa nico
de comparao de fases cruzadas de
projetos (Phase-cross-project). Isso
implica num processo formal que
compara os resultados de cada projeto e
observa especialmente o plano ou as
situaes construdas que podem

PMI Virtual Library | www.PMI.org | 2007 Project Management Institute


impactar negativamente cada projeto. As
equipes de programa, ento, avanam
para resolver as expectativas e consentir
na abordagem final para a integrao.

programa, mas a longo prazo, criar um

resultado de melhor qualidade.

Essa fase nica no limitada para o

sistema ou plano do processo. Ela
tambm pode ser aplicada em outros
processos com projetos tais como:
treinamentos, controles ps incio,
comunicaes, licenciamento,
contratao e outros componentes. O
aceite das concluses dessa fase tornase, ento, o ponto inicial para que todos
os projetos prossigam. Nesta conjuntura,
no necessrio que todas as equipes de
projeto evoluam juntas. Um novo plano
de incio-trmino pode ser aplicado com
risco e repetio de trabalho reduzidos.

Em concluso, o gerenciamento de
programas uma maneira slida e
benfica para as organizaes
gerenciarem grupos de projetos.
Quando consistentes e integrados, os
processos so aplicados para cada um
dos projetos dentro de um programa, os
riscos podem ser reduzidos e a
qualidade melhorada, o que contribui
para os objetivos gerais da iniciativa. Os
controles de amostras evidenciadas no
presente artigo so o incio de qualquer
considerao do gerenciamento de
programas, e quando aplicados a
caractersticas de outros programas,
podem ser considerados um sucesso
para todos.

Teste Integrado do Programa

Concluso

Sobre o autor
Enquanto a abordagem de nico
incio-continuao mltipla funciona
bem para reduzir riscos iniciais cruzados
de planos de projetos, esse teste
integrado no pode ser aplicado
posteriormente de forma fcil, em um
programa, se os projetos separados j
tiverem sido iniciados mas terminaro
em tempos diferentes. Isso, depois, se
transforma num risco significativo para a
qualidade e repetio de trabalho. Ele se
torna especialmente difcil quando as
datas de trmino de alguns projetos
forem prximas uma das outras. A
ocasio para o teste integrado ir, em
ultima anlise, impactar o cronograma e
o custo de uma equipe.
A nica estratgia para eliminar esse
risco inspecionar cada projeto como
se fosse um novo lanamento e efetuar
um sistema excepcional, testes de
regresso e execuo como parte dos
objetivos da segunda equipe. Isso
provavelmente eliminar um benefcio do

Diane Haubner, CISA, PMP uma

consultora de gerenciamento veterana
com mais de 19 anos de experincia em
design, desenvolvimento, implementao
e suporte de iniciativas estratgicas de
negcios e sistemas de informao em
diversas indstrias e ambientes. Ela
possui mais de 15 anos de experincia
como gerente de projetos. Ela tambm
possui experincia em planejamento
estratgico, avaliao de tecnologia,
implementao de melhores prticas,
engenharia de processos empresariais,
design de escritrios de gerenciamento
de programas, portflios e projetos,
desenvolvimento de aplicaes, sistema
de auditoria de informao e controles e
organizao de TI. Sua experincia em
consultoria tem variado entre
companhias da Fortune 500 a
companhias iniciantes dentre mltiplas
indstrias, incluindo manufatura, sade,
seguros, setor pblico, ensino superior e
servios profissionais.

PMI Virtual Library | www.PMI.org | 2007 Project Management Institute