Gerenciamento de Projetos de Tecnologia Da Informação (Marconi Vieira)

GERENCIAMENTO DE PROJETOS
DE TECNOLOGIA DA INFORMAÇÃO
CAMPUS — GERENCIAMENTO DE PROJETOS DE TECNOLOGIA DA INFORMAÇÃO — 1202 — CAPÍTULO 21 — 2ª PROVA

Preencha a ficha de cadastro no final deste livro
e receba gratuitamente informações
sobre os lançamentos e as promoções da
Editora Campus/Elsevier.
Consulte também nosso catálogo

completo e últimos lançamentos em
www.campus.com.br

GERENCIAMENTO DE PROJETOS
DE TECNOLOGIA DA INFORMAÇÃO

© 2007, Elsevier Editora Ltda.
Todos os direitos reservados e protegidos pela Lei 9.610 de 19/02/1998.

Nenhuma parte deste livro, sem autorização prévia por escrito da editora,
poderá ser reproduzida ou transmitida sejam quais forem os meios empregados:
eletrônicos, mecânicos, fotográficos, gravação ou quaisquer outros.
Copidesque: Carolina Godoi da Costa

Editoração Eletrônica: Estúdio Castellani
Revisão Gráfica: Roberto Mauro Facce
Projeto Gráfico
Elsevier Editora Ltda.
A Qualidade da Informação.
Rua Sete de Setembro, 111 – 16º andar
20050-006 Rio de Janeiro RJ Brasil
Telefone: (21) 3970-9300 FAX: (21) 2507-1991
E-mail: info@elsevier.com.br
Escritório São Paulo:
Rua Quintana, 753/8º andar
04569-011 Brooklin São Paulo SP
Tel.: (11) 5105-8555
ISBN 13: 978-85-352-2273-9

ISBN 10: 85-352-2273-1
Nota: Muito zelo e técnica foram empregados na edição desta obra. No entanto, podem ocorrer erros
de digitação, impressão ou dúvida conceitual. Em qualquer das hipóteses, solicitamos a comunicação à
nossa Central de Atendimento, para que possamos esclarecer ou encaminhar a questão.
Nem a editora nem o autor assumem qualquer responsabilidade por eventuais danos ou perdas
a pessoas ou bens, originados do uso desta publicação.
Central de atendimento
Tel.: 0800-265340
Rua Sete de Setembro, 111, 16º andar – Centro – Rio de Janeiro
e-mail: info@elsevier.com.br
site: www.campus.com.br
CIP-Brasil. Catalogação-na-fonte.
Sindicato Nacional dos Editores de Livros, RJ
V716g Vieira, Marconi Fábio

2.ed. Gerenciamento de projetos de tecnologia da informação /
Marconi Fábio Vieira. – 2.ed. totalmente rev. e atualizada. –
Rio de Janeiro : Elsevier, 2007
il.
Apêndice
Inclui bibliografia
ISBN 85-352-2273-1
1. Administração de projetos. 2. Tecnologia da informação.
I. Título.
06-3470. CDD 658.404

CDU 65.012.2

Dedicado aos meus pais, irmãos, esposa e filho
e a todos os meus familiares, amigos, colegas
de trabalho, alunos, conterrâneos Mineiros da cidade
de Timóteo e ao Povo Brasileiro.

Agradecimentos
Primeiramente agradeço a Deus pelo Seu Amor, pela Sua Palavra, por ter planejado o
projeto da minha concepção, pelo Renovo e pelas direções que me forneceu ao escrever
esta obra.
Um obrigado de todo coração aos meus pais, Jorge e Mara, pela criação, educação,
valores morais, éticos, culturais e profissionais que me proporcionaram. Agradeço
aos meus irmãos, Périclys e Flávio, pela união e pela infância compartilhada, nas quais
fizemos muitas “artes”. Meus pais e meus irmãos: amo vocês!
Um agradecimento com muito amor à minha esposa, Ana Paula, e ao meu filho,
Thomas, pela felicidade de tê-los comigo construindo o projeto da nossa família. Mi-
nha esposa e meu filho: amo vocês!
Este livro, ou melhor, este projeto, não poderia ser escrito sem a nobre iniciativa da
Editora Campus/Elsevier de investir na produção de novos autores nacionais. São
iniciativas como essa que lhe concedem um lugar de destaque no mercado editorial.
Obrigado a Campus/Elsevier e ao seu presidente, pela confiança em meu trabalho.
Agradeço também ao Consultor Editorial, Raul Colcher, e a Raquel Zanol, Kátia Alves e
Viviane Costa.
Agradeço a Ricardo Viana Vargas (PMP), por ter escrito o prefácio da primeira edi-
ção deste livro e à sua organização, Grupo A&C, pelo apoio institucional à publica-
ção deste livro. Aos amigos: Paulo Furtado, Matheus Fogli, Márcio Aleixo, Carlos Magno,
Rogrido Meira, Alexssandro, Fernando e Ramon.

VIII GERENCIAMENTO DE PROJETOS DE TECNOLOGIA DA INFORMAÇÃO
MARCONI FÁBIO VIEIRA
Um agradecimento especial ao mestre, amigo e escritor Danúbio Becker Borba

(PMP) por ter gentilmente escrito o prefácio da segunda edição.
Um agradecimento ao escritor, Mestre em Ciências Contábeis, professor e amigo
Carlos Alberto dos Santos Silva pelo apoio pessoal, acadêmico e profissional.
Agradeço aos idealizadores e a todo o corpo docente e discente do Business Insti-
tute (Campinas – SP), onde tive o privilégio, a honra e a oportunidade ímpar de
aprender muito com professores incríveis e compartilhar conhecimentos e expe-
riências profissionais através da realização do curso “MBA Executivo Internacional
de Tecnologia da Informação Aplicada a Gestão Estratégica de Negócios”. Um abra-
ço a todos os professores e alunos da turma TIGEN7. Obrigado a Nelson Antônio Roge-
ri, Gestor de Aprendizagem e Relacionamento; e ao Professor Agliberto Alves Cierco,
Coordenador de Área Adjunto Coordenador Acadêmico.
Meus agradecimentos se estendem também a todo o corpo docente e discente da
FIAP (Faculdade de Informática e Administração Paulista) e a Douglas Rodrigues, Di-
retor do Centro de Pós-graduação.
Também gostaria de agradecer a RNP por gentilmente ceder as informações so-
bre o seu “Histórico” e sobre o “Projeto Internet no Brasil”, publicadas neste livro.
Um agradecimento de irmão ao Sr. Osvaldo Gonçalves Morales e a todos os colabora-
dores de sua organização.
Agradeço também a Mara Santos, Gilberto Fernandes, Caetano A. Silva, Felipe Andres
León Garcia, Maria Helena De Sá C. Benaim, Rosangela Kronig, André Webber, Milton Abra-
hão, Sebastião Castilho, Yoshimi Narita, Fábio L. Quirino Homem, Alexandre Altheman, Ma-
ria José F. Altheman, Pedro Corrêa e Dan Sharoni.
Algumas empresas e pessoas colaboraram com estudos de casos, idéias e artigos
que serviram de fonte de inspiração, e foram adaptados neste livro. Meus sinceros
agradecimentos vão para:
Petrobras (Petróleo Brasileiro S.A.): A José Pedro Gonçalves e a Luiz Otávio Soares
Dornellas.
Siemens do Brasil: Ao Diretor de Tecnologia, Jairo Martins. À Assessoria de
Imprensa: Márcia Siqueira Costa Marques, Ana Maria de Oliveira Oliva e Ca-
rolina Pace Morango Guerrero.
Way Brasil TV - Belo Horizonte: A Melchiades Gonçalves de Souza Neto e a Anísio
G. Santos Júnior.
ABGP (Associação Brasileira de Gerenciamento de Projetos): Ao Presidente, Silvio de
Castro Wille, PhD., ao Vice-Presidente, Jorge Luciano Gil Kolotelo e à Dire-
tora Financeira, Lisiane Zynger Capaverde, MSc.
IIL (International Institute for Learning): Ao Managing Director, Mário Luis Sam-
paio Pereira.
Professor Fernando Carvalo, CEFET-SP (Centro Federal de Educação Tecnológi-
ca de São Paulo).

AGRADECIMENTOS IX
Francesco de Cicco, Sócio-fundador e Diretor-executivo do QSP (Centro de

Qualidade, Segurança e Produtividade).
Gianni Ricardi, Diretor do Comitê de Tecnologiada Anefac, Consultor de IT
Governance da Visanet e autor da Metodologia Sigmerk.
Coordenador e Professor Dr. Paulo Schmidt, do Núcleo de Estudos e Pesquisas em
Contabilidade da Universidade Federal do Rio Grande do Sul.
Agradeço a Joann Skiba, Director, IP and Business Product Development, da

ISACA; a Marvin Gelhausen, Managing Editor, da AACE International, Publisher of
the Cost Engineering journal e a Andy Vik, Customer Care Representative, American
Society for Quality, por terem concedido a permissão para eu disponibilizar no CD
que acompanha este livro alguns arquivos sobre os programas de certificações dessas
associações profissionais.
Agradeço a Peter Berndt de Souza Mello, PMP, Diretor de Tecnologia e Novos Ne-
gócios da X25 pelo apoio e disponibilização de informações sobre o software Spider
Project.
Um agradecimento especial ao meu sogro, Florisvaldo da Silva Alves e ao meu cu-
nhado, Leonardo Clemente Thomáz Lopes e Silva, pelo apoio logístico em um momento
ímpar da minha carreira profissional.
A Aguinaldo de Souza dos Santos e aos funcionários da Assescon, pela excelente as-
sessoria contábil que vêm prestando à minha empresa.
Aos amigos e grandes profissionais que conheci nas empresas nas quais prestei
consultorias de gerenciamento de projetos e de tecnologia da informação: FIAT
World Wide Purchasing (José Orlando, Luiz Otávio Tertuliano, Marco Aurélio Speziali,
Francisco Braga, Ronaldo Freitas Vieira, André Starlling, Guilherme Carrato, Feliciano Antô-
nio Mendes, Rodrigo Gontijo e Marcelo Avelar Tonelli); Gerdau-Açominas (Francisco Leal,
Andréia, Dener, José Joaquim, Marlene, Henrique); CEMIG (Sérgio Papa, Marco Aurélio e
Pedro Almeida); Infraero; CST - Companhia Siderúrgica de Tubarão (Caldellas, Rogé-
rio, Tadeu, Flávio, Fábio, Rosana, Davi, Rafel, Bernadete, Márcio, Buzato e Isaías); Remix
Tecnologia (Marcos Tito e Fátima).
Agradeço a todos os colaboradores da Petrobras - REGAP (Refinaria Gabriel Pas-
sos), Betim, Minas Gerais, onde trabalho atualmente como consultor apoiando no
planejamento de projetos de grande porte e na implementação de software corpora-
tivo de gerenciamento de projetos. Agradecimentos especiais ao Gerente Geral La-
fraia, a Maria de Lourdes Greco e aos colaboradores do EM: Alexandre, Aline, Juliana,
Campolina, Aluízio, Andréia, Canhestro, Antônio, Dussé, Eustáquio, Claudius, Diogo, Elia-
na, Belas, Fábio, Felipe, Fernando Garcia, Fernando Sigilião, Frederico, Ueta, Gastão, Pedro-
sa, Ionara, Ivone, Jasiel, João Eustáquio, Joel, José Antônio, Keyla, Luciana H., Luciana P.,
Lúcio Flávio, Quinaud, Lúcio Flávio Pelluci, Casali, Noschang, Marcelo, Cattony, Jéber, Me-
lissa, Miguel, Milton Igino, Natália, Nathan, Nelson, Níkolas, Nilton, Paulo Gomes, Paulo
Henrique, Paulo Nascimento, Pedro, Priscila, Raquel, Reinaldo, Cestari, Ricardo Nobre, Ro-

X GERENCIAMENTO DE PROJETOS DE TECNOLOGIA DA INFORMAÇÃO
bert, Roberta, Roberto Carlos, Rodrigo Cenizio, Rodrigo Zolini, Bretas, Rosângela, Samuel,
Sandra, Tomaz, Vânia, Vanderlei, Vinicius, Vitor Meniconi, Waldemar e Walter. Aos cola-
boradores da IERG: Gilson, Isabel, Carlos, Cláudio, Flávia, Hilário, Igreja, Karin, Lean-
dro, Luis Francisco, Rafael, Renato, Ronaldo, Emanuel, Richardson, Roberto, Tânia, Henri-
que, Jackson, Marisa, Aline, Élson, Fábio, Fon, Gilberto, Júnio, Luciana, Robson, Vicente, Vi-
nicios, Wiliam, Cristóvão, Ermar, Fábio Papale, Jair Donizete, Karine, Kátia , Marciela,
Obede, Ronaldo, Valdir, Valéria, Vanderlei, Vanderson, Ademir, Agnaldo, Carlos Cezar,
Cynthia, Daniela, Deusdete, Edvaldo, Hiran, João Roberto, Juliana, Júnio, Mário, Paulo,
Rildo, Sérgio, Teles, Toninho Aguiar, Túlio, Vinicius, Vladimir, Wanderley e Warley. Aos
meus amigos do ônibus: Lourenço, Luiz, Arimatéia, Rafael, Caio, Julião e Jerônimo. Aos
colaboradores da TI: Alberto, Alvim, Júlio, Rogério, Warley, Cristiano e Pimentel.
E um agradecimento especial, a você, leitor(a), por adquirir esta obra. Espero que
ela agregue muitos valores à sua vida pessoal e profissional!

Sobre o Autor
Marconi Fábio Vieira trabalha com Tecnologia da Informação desde 1985. É certi-
ficado pelo PMI como PMP (Project Management Professional) desde abril de 2003. É
especialista em gerenciamento de projetos de Tecnologia da Informação; em desen-
volvimento de metodologias de gerenciamento de projetos; em implementação de es-
critório de projetos (PMO) e em avaliação de nível de maturidade de gestão de proje-
tos nas organizações, e ministra treinamentos de GP e de gestão empresarial.
Possui as seguintes certificações na área de Tecnologia da Informação: MCT (Mi-
crosoft Certified Professional), MCT (Microsoft Certified Trainer), CUE (Certified
Unicenter Engineer), CUA (Certified Unicenter Administrator), CACP Storage
Specialist e CNS (Certified Novel Salesperson).
Prestou consultorias de gerenciamento de projetos para empresas de grande por-
te, tais como FIAT World Wide Purchasing, Gerdau-Açominas, CEMIG, Infraero
(DF) e CST (Companhia Siderúrgica de Tubarão). Na área de Tecnologia da Infor-
mação, prestou serviços para diversas organizações tais como Remix Tecnologia,
MSA Infor, Banco Banestes (ES), Logic Way, Centro de Computação da Aeronáuti-
ca (RJ), DAC, DEPV e Banco Bradesco.
É instrutor de cursos de gestão empresarial e gerenciamento de projetos, incluin-
do metodologia de GP e treinamento preparatório para o exame de certificação PMP
do PMI.
É membro associado das seguintes associações profissionais: ABGP (Associação
Brasileira de Gerenciamento de Projetos); PMI (Project Management Institute – Ca-

XII GERENCIAMENTO DE PROJETOS DE TECNOLOGIA DA INFORMAÇÃO
pítulo Minas Gerais); IEEE Computer Society; ISACA (Information Systems Audit
and Control Association); AACE (The Association for the Advancement of Cost
Engineering); PRMIA (Project Risk Management Internacional Association) e Insti-
tuto de Engenharia (SP).
Atua como voluntário no desenvolvimento de padrões internacionais do PMI,
tendo participado da elaboração do OPM3, primeira e segunda edições.
É consultor editorial de livros nas áreas de gerenciamento de projetos, Tecnologia
da Informação e administração.
Cursou MBA Executivo Internacional de Tecnologia da Informação Aplicado à
Gestão Estratégica dos Negócios na FGV e na Ohio University. Possui graduação em
Tradutor e Intérprete pelas Faculdades Integradas Newton e Pós-graduação em lín-
gua espanhola pelo Instituto Pinar Del Rio – Cuba.
Realiza traduções profissionais e voluntárias de livros e artigos relacionados à ges-
tão de projetos e tecnologia da informação para a comunidade de TI e de gerencia-
mento de projetos do Brasil. É o tradutor oficial e voluntário para a língua portugue-
sa dos artigos do Risk Doctor, de autoria do Dr. David Hillson, sobre gestão de riscos.
Atualmente trabalha como consultor na Petrobras (REGAP – Refinaria Gabriel
Passos, Betim, Minas Gerais), atuando no planejamento e fiscalização dos projetos
de grande porte e na implementação de ferramentas de gerenciamento de projetos
corporativos.
Pode ser contatado em: marconi@infochoice.com.br e marconivieira@compu-

ter.org

Prefácio da
Primeira Edição
Desde meados de 1990, o gerenciamento de projetos tem apresentado um cresci-

mento muito significativo em sua utilização, principalmente a partir do final dessa
década. Essa ampliação espetacular tem provocado diversos questionamentos, den-
tre eles o porquê de tanta velocidade.
Certamente essa velocidade não diz respeito apenas à nossa área específica, e, sim
a todo um contexto cultural global muito mais amplo. Nesse cenário, o gerencia-
mento de projetos veio preencher uma lacuna existente na atividade profissional hu-
mana, tentando responder aos eventuais desafios e às necessidades contínuas de su-
peração, para que, de modo constante, possamos planejar todo o trabalho e “fazer
mais com menos”, rompendo sempre os limites preestabelecidos.
Muitas vezes, em minhas aulas e palestras, cito a “Seleção Natural”, de Darwin,
para justificar a extinção de determinadas espécies. “Somente as espécies fortes e
adaptadas ao ambiente sobreviverão.” E essa adaptação ao ambiente certamente
passa, dentre outras coisas, pelo aumento da capacitação profissional das pessoas
para trabalharem com o novo. O gerenciamento de projetos é exatamente lidar
com o novo, com aquilo que está no limiar entre o possível e o impossível.
Isso se justifica quando analisamos o cenário atual, no qual observamos que as de-
cisões que mudam o mundo não são mais tomadas em anos, e sim, em segundos, e
precisamos estar preparados para lidar com novidades e desafios de modo perma-
nente, como parte do nosso dia-a-dia.
Como cita o Professor Harold Kerzner, é preciso que mudemos nosso ponto de
vista, saindo de uma visão convencional do trabalho e partindo para uma visão tem-

XIV GERENCIAMENTO DE PROJETOS DE TECNOLOGIA DA INFORMAÇÃO
porária ou de projetos, na qual todos os esforços são orientados para os objetivos,

dentro de um cenário limitado de tempo (início, meio e fim).
Nesse cenário, o novo substitui a rotina, e a capacidade de planejar aquilo que é
novo requer habilidades diferentes do profissional: habilidades de comunicar-se, de
gerenciar pessoas, de lidar com a competitividade crescente de modo otimista e ver-
dadeiro, a capacidade de lidar com obstáculos de forma proativa, a capacidade de se
motivar e de motivar a equipe, a capacidade de trabalhar sob pressão, dentre outras.
Atualmente, essas habilidades superam em muito determinados conhecimentos téc-
nicos específicos.
Não estou apresentando aqui a mudança. Falo, agora, da velocidade e da comple-
xidade com que ela ocorre. Temos, hoje, operações cada vez mais complexas, com
cada vez menos recursos e com cada vez mais procura por resultados. E por que não
falo de mudança? Desde que o mundo é mundo, existe a mudança. Certamente,
quando Newton desenvolveu as três leis sobre a força, revolucionou o mundo, assim
como Arquimedes que, em “seu banho de banheira”, desenvolveu a teoria do empu-
xo. Certamente, esses cientistas mudaram o mundo. A questão, agora, é que temos
um “José Newton”, ou um “Arquimedes da Silva” por segundo, prontos para criar
uma nova ordem mundial ou para revolucionar o mundo. Esses são os novos pilares
da tão vivenciada “globalização”.
Existe, ainda, um aspecto sobre o qual muitos de nós não falamos, ensinamos, es-
crevemos ou queremos pensar: a nossa responsabilidade social.
Ao desenvolvermos essas habilidades, procuramos o prêmio que os que conse-
guem ter velocidade suficiente para superar recebem, penalizando, muitas vezes, os
menos favorecidos. É tremendamente importante que tenhamos o sentimento de
estarmos fazendo algo que significa muito mais do que apenas construir negócios,
empresas e projetos, visando nossas recompensas financeiras. Temos de estar con-
vencidos de que fazemos algo de considerável importância para o mundo, para a
sociedade em que vivemos.
Ricardo Viana Vargas
MSc, PMP
Ricardo Viana Vargas é especialista em planejamento, gestão e controle de projetos, membro do Project Management Institute, maior orga-
nização do mundo voltada para a administração de projetos, da Association for Advancement of Cost Engineering, da American Manage-
ment Association e da International Project Management Association. É autor de cinco livros e diversos artigos sobre gerenciamento de proje-
tos no país e no exterior. É certificado pelo PMI como Project Management Professional (PMP) e pela Microsoft como Microsoft Certified Offi-
ce User Specialist em MS Project 2002, tendo atuado ativamente nos testes Beta de versões do MS Project 98, 2000 e 2002. É revisor reco-
nhecido da mais importante referência no mundo sobre gerenciamento de projetos, o PMBOK Guide 2000, e membro da equipe de projetos de
atualização do PMBOK Guide 2004. Atua como sócio diretor do Grupo A&C, conjunto de empresas especializadas em tecnologia e ge-
renciamento de projetos. É responsável por mais de vinte projetos de grande porte no Brasil, gerenciando uma equipe de mais de cem profissio-
nais, integralmente dedicada à terceirização e outsourcing em projetos nas áreas de telecomunicações, informática, finanças e energia, com
um portfolio de investimentos superior a 5 bilhões de dólares. É engenheiro químico e mestre em Engenharia de Produção pela Universidade
Federal de Minas Gerais com Master Certificate em Gerenciamento de Projetos pela George Washington University. É vice-presidente de ge-
renciamento de projetos da Sucesu-MG e fundador do Project Management Institute – Regional Minas Gerais.

Prefácio da
Segunda Edição
Cada vez mais o termo gerenciamento de projetos tem sido citado na imprensa, princi-
palmente na televisão. Os diferentes canais têm incluído diariamente em sua grade
de programação documentários mostrando grandes projetos, exibindo técnicas ino-
vadoras e verdadeiros monumentos dignos de serem chamados de maravilhas mo-
dernas, grandes construções ou obras incríveis.
Curiosamente, também temos observado programas que tratam de atividades não
tão monumentais tais como a remodelação de residências de famílias geralmente em
dificuldades feitas em prazos agressivos, normalmente em menos de uma semana.
Muitos desses programas exibem projetos que vão desde a elaboração de filmes e
outros a lançamentos de coleções de roupas. Pequenos ou grandes, simples ou mo-
numentais todos esses programas têm destacado um elemento comum para a supera-
ção dos desafios impostos: a importância do trabalho de equipe e em especial a con-
tribuição do seu líder – o gerente de projetos.
Alguns programas tais como O Aprendiz colocam em xeque as habilidades geren-
ciais de seus participantes por meio de desafios em que a maior dificuldade não é a
gincana semanal de realizar as tarefas solicitadas, mas sim de coordenar com maestria
os recursos disponíveis para que o resultado seja alcançado.
O que podemos concluir é fato já citado por centenas de autores em suas obras – o
interesse pelo papel de coordenar os recursos para se alcançar um resultado está au-
mentando. Outras disciplinas técnicas têm mostrado um grande interesse pelo
tema, além de investimentos generosos na qualificação de seus profissionais. O que

XVI GERENCIAMENTO DE PROJETOS DE TECNOLOGIA DA INFORMAÇÃO
era assunto de engenheiros e profissionais de Tecnologia da Informação está se disse-

minando por outras paragens.
Felizmente, para nós profissionais de TI as outras áreas de negócio também preci-
sam gerenciar seus projetos com mestria e competência, e elas estão buscando novas
práticas que melhorem seus indicadores de sucesso. Como a grande maioria dos pro-
jetos requer componentes de TI, isso nos faz participar intensamente de todas as ini-
ciativas, e nos obriga a desenvolver cada vez mais a nossa competência para gerenciar
com eficácia os projetos.
E é justamente para isso que este livro foi escrito, para que nós profissionais de
Tecnologia da Informação possamos estar sempre “antenados”, parafraseando meu
amigo Marconi.
A profissão tem atraído cada vez mais pessoas que buscam a capacitação. Nos di-
versos treinamentos que ministro tenho observado a quantidade de interessados
pelo assunto.
Este livro deve fazer parte da sua biblioteca pessoal, pois fornece informações va-
liosas que ajudará você no desenvolvimento de suas competências e em vários insigths
para gerenciar projetos de Tecnologia da Informação.
Professor Danúbio Borba Beker Borba, PMP

Instrutor certificado pelo PMI®. É PMP® desde 1998 e possui larga experiência em treina-
mento na área de gerenciamento de projetos e no preparo de profissionais para a certificação.
Atuou como instrutor na IBM Brasil por dez anos e possui experiência acadêmica nos cursos da
FGV Management; MBA FIA/USP; Fundação Dom Cabral na área de administração de proje-
tos e FIAP (www.fiap.com.br). Danúbio Beker Borba, junto com Ricardo Viana Vargas e José
Finocchio receberam, no dia 10 de setembro, no Canadá, o Prêmio PMI Professional Develop-
ment of the Year na categoria educacional, reconhecimento do Project Management Institute
(PMI), principal centro internacional na área de gerenciamento de projetos, pela criação do
instrumento pedagógico chamado PMDome. É a primeira vez que profissionais brasileiros rece-
bem este prêmio. Também é autor colaborador do primeiro livro brasileiro dirigido à certifica-
ção PMI®: Como se tornar um profissional em gerenciamento de projetos, coordena-
do pelo Professor Paul Dinsmore e editado pela QualityMark e de Gerenciamento do tempo
em projetos da FGV Editora.

Introdução
“Livros não mudam o mundo,
quem muda o mundo são as pessoas.
Os livros só mudam as pessoas”.
MÁRIO QUINTANA
Quando se publica a segunda edição de um livro, em primeiro lugar, é necessário

agradecer a todos os leitores pela boa receptividade e aquisição da primeira edição,
lançada em junho de 2003.
Além disso, estendo os meus agradecimentos à Editora Campus/Elsevier, pela
dedicação editorial, parceria e confiança no meu trabalho. Naquela época, em
2003, graças à nobre iniciativa da Editora Campus de investir em novos talentos e
temas, eu estava estreando como autor. Hoje, graças a Deus, a você e a Campus,
posso afirmar que conquistei um lugar no mercado editorial, motivado pelo desejo
de compartilhar com você as minhas experiências e de contribuir com a ampliação
da base de conhecimento sobre gerenciamento de projetos e tecnologia da infor-
mação no Brasil.
A produção da segunda edição é resultado de um trabalho intenso de pesquisas,
consultas e análises de todo material disponível a que tive acesso, como livros, revis-
tas, jornais, apresentações, arquivos, sites na Internet, cursos, seminários, congres-
sos e experiências profissionais.
Além disso, tive a colaboração de algumas pessoas e empresas que autorizaram a
publicação de artigos e estudo de casos para ilustrar os assuntos e constatar o sucesso
e a aplicabilidade das práticas apresentadas. A essas pessoas e empresas quero expres-
sar os meus sinceros agradecimentos.

XVIII GERENCIAMENTO DE PROJETOS DE TECNOLOGIA DA INFORMAÇÃO
Revisada
Sabemos que os dias de hoje são testemunhas de uma verdadeira revolução no mun-
do dos negócios, principalmente no desenvolvimento de novas tecnologias e concei-
tos de gestão. Então, é natural disponibilizar para o leitor informações mais atualiza-
das, já que as mudanças fazem parte do jogo desse mercado globalizado. Por isso re-
visei todo o conteúdo do texto da primeira edição, tendo como ponto de partida a
observação do que mudou no cenário mercadológico de gerenciamento de projetos
e de tecnologia da informação.
Fui motivado pela publicação da Terceira Edição do PMBOK, que contém novos
processos e conteúdos. Dessa maneira, tornou-se necessário adaptar a nomenclatura
das melhores práticas do PMI e refleti-la na Segunda Edição.
Fui estimulado também pelo lançamento de novas versões dos aplicativos de ge-
renciamento de projetos que acompanharam o CD da primeira edição. Agora, além
de aqueles aplicativos estarem mais atualizados, foi disponibilizado no CD que
acompanha este livro novos aplicativos. Como “tempo é dinheiro”, você economiza-
rá horas preciosas de downloads utilizando os aplicativos desse CD.
Ampliada
E como era de se esperar, no decorrer de alguns anos, muitas mudanças ocorreram
no cenário internacional, diversos temas de TI e administrativos foram ganhando
destaque no mercado. Uma profusão de livros foi publicada, da qual gostaria de res-
saltar a qualidade ímpar dos livros da Editora Campus/Elsevier.
Por necessidade profissional e por prazer pessoal, procuro acompanhar de perto
as megatendências administrativas e estar sempre antenado ao mercado. Sou um lei-
tor voraz e assíduo de livros de gestão e de TI. Tive a oportunidade de ler excelentes
livros e decidi compartilhar com você os conhecimentos que adquiri nesse período.
Com enfoque em tecnologia da informação, abordei de maneira sucinta temas
como conceito de tecnologia da informação, TI e os departamentos da empresa, tec-
nologia e economia, TI e as pressões do mercado, planejamento dos sistemas de in-
formação, um modelo de planejamento de TI, Método PPTI – Priorização de Proje-
tos de Tecnologia da Informação, Governança de TI, ITIL, COBIT, Sarbanex-
Oxley, alguns estudos de casos, Segurança da Informação e as novas normas ISO
aplicadas à TI.
Sobre gerenciamento de projetos e assuntos correlatos, incluí alguns temas e arti-
gos sobre gestão de riscos, Seis Sigma e a apresentação da metodologia UPMM, a
abordagem do IIL para a capacitação em gerenciamento de projetos, baseada no
Enfoque Kerzner para Excelência em Gerenciamento de Projetos.
Foram incluídas também novas associações profissionais de reconhecimento in-
ternacional com seus programas de certificações. Essas associações são essenciais
para o fomento e desenvolvimento da profissão gerente de projetos.

INTRODUÇÃO XIX
Além disso, foram adicionados três Apêndices: “Seleção de 50 Conceitos de Ges-

tão”, “Melhores Práticas para Gestão de Projetos Governamentais” e “Artigos Tra-
duzidos de Gerenciamento de Riscos”.
No decorrer dos capítulos o leitor encontrará uma extensa referência bibliográfi-
ca, bem como artigos e sites na Internet, de acordo com os respectivos assuntos.
Consideração Final
O intuito da segunda edição é agregar ainda mais valores para você, sem a finalidade
de esgotar os assuntos ou aprofundar-se excessivamente.
É sabido que por mais cuidadosa que tenha sido a revisão e ampliação deste livro,
elas não estão isentas de sugestões e críticas por parte dos leitores, que são peças fun-
damentais, a fim de mantermos um canal de comunicação aberto para melhoramen-
tos e refinamentos da obra como um todo para as próximas edições. Por isso, para man-
termos a nossa parceria e um canal de comunicação cada vez mais estreito, informo o
meu e-mail para contatos: marconi@infochoice.com.br
Mais uma vez obrigado, e que Deus te abençoe!
Cordialmente,
Marconi Fábio Vieira, PMP

MCT, MCP, CUE, CUA,
CACP Storage Specialist, CNS

Sumário
PARTE I
Introdução ao gerenciamento de projetos
CAPÍTULO 1 Tecnologia da informação, governança de TI e introdução
ao gerenciamento de projetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Tecnologia da Informação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Conceito de tecnologia da informação. . . . . . . . . . . . . . . . . . . . . . . . 3
A TI e os departamentos da empresa. . . . . . . . . . . . . . . . . . . . . . . . . 4
Tecnologia e economia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
A TI e as pressões do mercado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Planejamento dos sistemas de informação . . . . . . . . . . . . . . . . . . . . . 8
Um modelo de planejamento de TI. . . . . . . . . . . . . . . . . . . . . . . . . . 9
Método PPTI – Priorização de Projetos de Tecnologia da Informação . 10
Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Governança de TI*. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
IT Governance: de onde veio, onde está e para onde vai . . . . . . . . . . 19
COBIT – estrutura do framework . . . . . . . . . . . . . . . . . . . . . . . . . 22
Otimização da estrutura dos processos de TI – COBIT, ITIL
e demais conceitos, metodologias e ferramentas . . . . . . . . . . . . . . . . 25

XXII GERENCIAMENTO DE PROJETOS DE TECNOLOGIA DA INFORMAÇÃO
Otimização do processo de tomada de decisão em TI . . . . . . . . . . . . . . . 29

ITIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Sarbanes-Oxley . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Introdução ao Gerenciamento de Projetos. . . . . . . . . . . . . . . . . . . . . . . 51
Conceito de Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Projetos versus operações rotineiras . . . . . . . . . . . . . . . . . . . . . . . . . 53
A história evolutiva do gerenciamento de projetos . . . . . . . . . . . . . . 54
O que é gerenciamento de projetos? . . . . . . . . . . . . . . . . . . . . . . . . 62
CAPÍTULO 2 O contexto e os processos do gerenciamento de projetos . . . . . . 73

Considerações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Fases e ciclo de vida dos projetos . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Os envolvidos no projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Influência das organizações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Principais habilidades do gerente de projetos . . . . . . . . . . . . . . . . . . 77
Influências socioeconômicas e ambientais. . . . . . . . . . . . . . . . . . . . . 77
Introdução aos processos de gerência de projetos . . . . . . . . . . . . . . . . . . 77
CAPÍTULO 3 O gerente de projetos antenado . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Gerenciamento da qualidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
A evolução do gerenciamento moderno da qualidade . . . . . . . . . . . . 80
Outros métodos que ajudam a melhorar a qualidade dos projetos . . . . 85
Normas ISO aplicadas à Tecnologia da Informação . . . . . . . . . . . . . . 92
Gerenciando pessoas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Teorias da motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Influência e poder. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Melhorando a eficiência. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Coaching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Princípios básicos de gerenciamento de custos . . . . . . . . . . . . . . . . . . . 104
TCM – Total Cost Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Considerações sobre tributos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Gestão de riscos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Seis Sigma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
UPMM – UNIFIED PROJECT MANAGEMENT METHODOLOGY. . . 124
Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

SUMÁRIO XXIII
CAPÍTULO 4 As peculiaridades dos projetos de tecnologia da informação

sob a ótica das nove áreas do conhecimento . . . . . . . . . . . . . . . 133
Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
O gerenciamento da integração em projetos de TI . . . . . . . . . . . . . . . . 134
O gerenciamento do escopo em projetos de TI . . . . . . . . . . . . . . . . . . 135
O gerenciamento do tempo em projetos de TI . . . . . . . . . . . . . . . . . . . 137
O gerenciamento dos custos em projetos de TI . . . . . . . . . . . . . . . . . . 139
O gerenciamento da qualidade em projetos de TI . . . . . . . . . . . . . . . . . 139
O gerenciamento dos recursos humanos em projetos de TI . . . . . . . . . . 140
O gerenciamento dos riscos em projetos de TI . . . . . . . . . . . . . . . . . . . 143
O gerenciamento das comunicações em projetos de TI . . . . . . . . . . . . . 148
O gerenciamento das aquisições em projetos de TI . . . . . . . . . . . . . . . . 150
PARTE II
Processos cronológicos de gerenciamento de projetos
CAPÍTULO 5 Processos de iniciação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Os processos de iniciação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Desenvolver o termo de abertura do projeto (4.1) . . . . . . . . . . . . . 160
Desenvolver a declaração de escopo preliminar do projeto (4.2) . . . . 161
Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
CAPÍTULO 6 Grupos de processos de planejamento . . . . . . . . . . . . . . . . . . . . 163

Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Os processos de Planejamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Desenvolvimento do plano de gerenciamento de projetos (4.3) . . . . 164
Planejamento do escopo (5.1) . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Definição do escopo (5.2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Criação da EAP (5.3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Definição da atividade (6.1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Seqüenciamento de atividades (6.2) . . . . . . . . . . . . . . . . . . . . . . . 167
Estimativas de recursos da atividade (6.3) . . . . . . . . . . . . . . . . . . . 167
Estimativa de duração da atividade (6.4) . . . . . . . . . . . . . . . . . . . . 167
Desenvolvimento do cronograma (6.5) . . . . . . . . . . . . . . . . . . . . . 168
Estimativa de custos (7.1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Orçamento (7.2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Planejamento da qualidade (8.1). . . . . . . . . . . . . . . . . . . . . . . . . . 169
Planejamento de recursos humanos (9.1) . . . . . . . . . . . . . . . . . . . . 170
Planejamento das comunicações (10.1) . . . . . . . . . . . . . . . . . . . . . 170

XXIV GERENCIAMENTO DE PROJETOS DE TECNOLOGIA DA INFORMAÇÃO
Planejamento do gerenciamento de riscos (11.1) . . . . . . . . . . . . . . 171

Identificação dos riscos (11.2) . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Análise qualitativa dos riscos (11.3). . . . . . . . . . . . . . . . . . . . . . . . 172
Análise quantitativa dos riscos (11.4). . . . . . . . . . . . . . . . . . . . . . . 172
Planejamento de respostas a riscos (11.5). . . . . . . . . . . . . . . . . . . . 172
Planejamento de compras e aquisições (12.1) . . . . . . . . . . . . . . . . . 173
Planejamento de contratações (12.2). . . . . . . . . . . . . . . . . . . . . . . 173
Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
CAPÍTULO 7 Processos de execução. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Os processos de execução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Orientação e gerenciamento da execução do projeto (4.4) . . . . . . . . 176
Realização da garantia da qualidade (8.2) . . . . . . . . . . . . . . . . . . . . 177
Controle e mobilização da equipe do projeto (9.2) . . . . . . . . . . . . . 177
Desenvolvimento da equipe do projeto (9.3) . . . . . . . . . . . . . . . . . 177
Distribuição das informações (10.2) . . . . . . . . . . . . . . . . . . . . . . . 178
Solicitação de respostas de fornecedores (12.3) . . . . . . . . . . . . . . . 178
Seleção dos fornecedores (12.4) . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
CAPÍTULO 8 Processos de monitoramento e controle . . . . . . . . . . . . . . . . . . 181

Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Processos de monitoramento e controle . . . . . . . . . . . . . . . . . . . . . . . 181
Monitoramento e controle do trabalho do projeto (4.5). . . . . . . . . . 182
Controle integrado de mudanças (4.6) . . . . . . . . . . . . . . . . . . . . . 182
Verificação do escopo (5.4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Controle do escopo (5.5) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Controle do cronograma (6.6) . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Controle de custos (7.3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Realização do controle da qualidade (8.3) . . . . . . . . . . . . . . . . . . . 184
Gerenciamento da equipe do projeto (9.4). . . . . . . . . . . . . . . . . . . 185
Relatório de desempenho (10.3). . . . . . . . . . . . . . . . . . . . . . . . . . 185
Gerenciamento das partes interessadas (10.4). . . . . . . . . . . . . . . . . 186
Monitoramento e Controle de riscos (11.6) . . . . . . . . . . . . . . . . . . 186
Administração de contrato (12.5) . . . . . . . . . . . . . . . . . . . . . . . . . 187
Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

SUMÁRIO XXV
CAPÍTULO 9 Processos de encerramento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Processos de encerramento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Encerramento do projeto (4.7). . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Encerramento do contrato (12.6) . . . . . . . . . . . . . . . . . . . . . . . . . 190
Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
PARTE III
A profissão gerente de projetos
CAPÍTULO 10 Associações e certificações profissionais para o gerente
de projetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
PMI – Project Management Institute . . . . . . . . . . . . . . . . . . . . . . . . . 196
Introdução. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Sobre o PMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Dados estatísticos sobre os associados do PMI no mundo . . . . . . . . . 197
Programa de certificação do PMI . . . . . . . . . . . . . . . . . . . . . . . . . 197
Project Management Professional . . . . . . . . . . . . . . . . . . . . . . . . . 198
Conteúdo e Forma do Exame. . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
CAQ – Certificate of Added Qualification . . . . . . . . . . . . . . . . . . . 201
Certified Associate in Project Management . . . . . . . . . . . . . . . . . . 201
Locais de realização das provas do PMI no Brasil . . . . . . . . . . . . . . . 202
Os capítulos brasileiros do PMI . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Lista atualizada dos capítulos do PMI no Brasil . . . . . . . . . . . . . . . . 203
ABGP – Associação Brasileira de Gerenciamento de Projetos . . . . . . . . . 207
Introdução. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Categoria de sócios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Resumo do estatuto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Como se associar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Parceiros e links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Contatos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Certificação em GP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Lançamento do novo ICB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Clube ABGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
AACE – The Association for the Advancement of Cost Engeneering . . . . 215
Introdução. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Benefícios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Novas certificações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Web site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
ISACA – Information Systems Audit and Control Association . . . . . . . . 216
Introdução. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Certificados profissionais: CISA e CISM. . . . . . . . . . . . . . . . . . . . . 217

XXVI GERENCIAMENTO DE PROJETOS DE TECNOLOGIA DA INFORMAÇÃO
PRMIA – The Professional Risk Managers’ International Association . . . 221

Introdução. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
PRMIA Institute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Certificação PRM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Recursos para os associados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Web site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
IEEE Computer Society . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Introdução. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Benefícios da associação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Cursos disponíveis no site do IEEE Computer Society para
membros associados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Business strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Cisco Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Desktop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
IP Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Leadership. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Operating Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Programming Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Project management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
XML. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
By certification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
ASQ – America Society for Quality . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Introdução. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Cursos preparatórios para o CSQE . . . . . . . . . . . . . . . . . . . . . . . . 236
Livros preparatórios para o exame . . . . . . . . . . . . . . . . . . . . . . . . 236
Lista de materiais de estudo para o exame CSQE . . . . . . . . . . . . . . 236
SHRM – Society for Human Resource Management . . . . . . . . . . . . . . . 238
Introdução. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Tipos de associações e taxas anuais . . . . . . . . . . . . . . . . . . . . . . . . 238
Certificações para o profissional de RH . . . . . . . . . . . . . . . . . . . . . 239
CompTIA – The Computing Technology Industry Association . . . . . . . . 239
Introdução. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Exemplos de questões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Web site e contatos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
CAPÍTULO 11 Exemplos de softwares de gerenciamento de projetos . . . . . . . 243

Considerações iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

SUMÁRIO XXVII
Task Tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244

TT Cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Atualização do cronograma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Criação de subtarefas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Monitoramento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Aprendizado nas tarefas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
TT Off-line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
TT Administrador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Visualizar log de monitoramento dos recursos . . . . . . . . . . . . . . . . 248
Gestão de usuários . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Gestão de projetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Conclusão sobre o Task Tracking . . . . . . . . . . . . . . . . . . . . . . . . . 248
WBS Chart Pro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Recursos do WBS Chart Pro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Requisitos do sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Pert Chart Expert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Recursos do PERT Chart EXPERT . . . . . . . . . . . . . . . . . . . . . . . . 253
Mindmanager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Benefícios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
Um Pequeno Tour pelo Produto . . . . . . . . . . . . . . . . . . . . . . . . . 261
Recursos Principais. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
Idiomas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Novos recursos do Mindjet MindManager Pro 6: . . . . . . . . . . . . . . 265
Microsoft Project 2002 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Perguntas e respostas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Microsoft Project Standard 2002 . . . . . . . . . . . . . . . . . . . . . . . . . 270
Microsoft Project Professional 2002 . . . . . . . . . . . . . . . . . . . . . . . 271
Microsoft Project Server 2002 . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
Microsoft Project Web Access . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
Benefícios de migração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
Benefícios do Microsoft Project Server . . . . . . . . . . . . . . . . . . . . . 276
Quadro comparativo entre as versões do Microsoft Project . . . . . . . 278
Nova Versão do Microsoft Project 2007 . . . . . . . . . . . . . . . . . . . . 280
Primavera Team Play . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Visão geral. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Informações sobre o produto Primavera TeamPlay . . . . . . . . . . . . . 281
A arquitetura funcional do produto . . . . . . . . . . . . . . . . . . . . . . . . 281
Recursos e especificações. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Suíte de componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283

XXVIII GERENCIAMENTO DE PROJETOS DE TECNOLOGIA DA INFORMAÇÃO
Contatos GanttHead . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285

Produtos complementares de parceiros Primavera Team Play. . . . . . 286
PMOffice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
PMOffice Enterprise Architecture . . . . . . . . . . . . . . . . . . . . . . . . 287
Time Tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
Project Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
Change, Issue e Risk Management . . . . . . . . . . . . . . . . . . . . . . . . 295
Project Document Management . . . . . . . . . . . . . . . . . . . . . . . . . . 295
Project Collaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
Reusable Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
Inter-project Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
Integration With Schedulers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
Capacity and Resource Planning . . . . . . . . . . . . . . . . . . . . . . . . . . 301
Portfolio Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
Open Project System (SAP). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
Open Project System Para Microsoft Project . . . . . . . . . . . . . . . . . 306
Arquitetura da tecnologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
Open Project para Palm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
Rational Project Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Processos configuráveis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
Gerenciamento dos requisitos e gerenciamento da configuração
de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
Relatos (apresentações) e métricas de progresso . . . . . . . . . . . . . . . 313
PS8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
Gerenciamento de múltiplos projetos . . . . . . . . . . . . . . . . . . . . . . 315
Múltiplas visões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
Segurança . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
Gerenciamento de Insights. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
Visões na Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
Aprendendo e utilizando o PS8. . . . . . . . . . . . . . . . . . . . . . . . . . . 321
Extensibilidade de banco de dados . . . . . . . . . . . . . . . . . . . . . . . . 322
Gerenciamento de portfolio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
Gerenciamento do Web site. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
Visualização de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
Integrated Report Writer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
Templates de projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
Nivelamento de recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
Gerenciamento de custos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
Gerenciamento de caminho crítico . . . . . . . . . . . . . . . . . . . . . . . . 325
Gerenciamento de corrente crítica . . . . . . . . . . . . . . . . . . . . . . . . 325
Project Communicator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326

SUMÁRIO XXIX
PC-Inform. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
PC-Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
PSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
Tassc Estimator Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Versões Atuais do Tassc Estimator . . . . . . . . . . . . . . . . . . . . . . . . 349
Spider Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
Telas do Spider Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
Palisade @RISK 4.5, Decision Tools e @RISK for Project. . . . . . . . 363
Kidasa Milestones Professional 2006 . . . . . . . . . . . . . . . . . . . . . . . 366
Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387
CAPÍTULO 12 Fomentando projetos de tecnologia da informação na

organização. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
Projetos estratégicos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
IT Governance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
Modelagem de Processos Empresariais . . . . . . . . . . . . . . . . . . . . . 390
Visão de processos de negócio . . . . . . . . . . . . . . . . . . . . . . . . . . . 391
Melhoria e redesenho de processos . . . . . . . . . . . . . . . . . . . . . . . . 391
Gerenciamento de processos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392
Pré-ERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
Projetos de infra-estrutura. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
Projetos de software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
Administração de dados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
Integração e customização de ferramentas CASE. . . . . . . . . . . . . . . 399
Migração entre ferramentas CASE de modelagem de dados . . . . . . . 400
Modernização de sistemas legados. . . . . . . . . . . . . . . . . . . . . . . . . 400
Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402
Um toque especial do Autor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405

APÊNDICE A Bibliografia sugerida. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
APÊNDICE B Informações complementares . . . . . . . . . . . . . . . . . . . . . . . . . . 413
APÊNDICE C Seleção de 50 conceitos de gestão . . . . . . . . . . . . . . . . . . . . . . . 423
Apêndice D Melhores práticas para gestão de projetos governamentais . . . 441
Apêndice E Artigos traduzidos sobre gerenciamento de riscos . . . . . . . . . . 459
Bibliografia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473
Índice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477

PA R TE I
Introdução ao
gerenciamento de projetos

CONSIDERAÇÕES
A primeira parte deste livro é dedicada aos conceitos básicos sobre tecnologia da in-
formação, à governança de TI e à introdução ao gerenciamento de projetos. Esta par-
te inclui os capítulos 1, 2, 3 e 4.
No Capítulo 1 veremos os seguintes temas: conceito de tecnologia da informação,
TI e os departamentos da empresa, tecnologia e economia, TI e as pressões do mer-
cado, planejamento dos sistemas de informação, um modelo de planejamento de TI,
governança de TI , ITIL, COBIT, Sarbanex-Oxley, estudos de casos de sucesso e
uma introdução ao gerenciamento de projetos.
O Capítulo 2 fornece informações sobre o contexto e os processos do gerencia-
mento de projetos, que envolve o ciclo de vida dos projetos, os stakeholders (as partes
envolvidas), os tipos de estruturas organizacionais, a influência das organizações, as
principais habilidades do gerente de projetos, as influências socioeconômicas e am-
bientais e uma introdução aos processos de gerência de projetos.
O Capítulo 3 aborda alguns conceitos e tendências afins à matéria gerenciamento
de projetos. Serão apresentados alguns aspectos relevantes sobre gerenciamento da
qualidade, recursos humanos, custos, tributos, riscos e Seis Sigma, além da metodo-
logia de gerenciamento de projetos UPMM.
E para encerrar a primeira parte do livro, veremos no Capítulo 4 as peculiaridades
dos projetos de tecnologia da informação sob a ótica das nove áreas do conhecimento.

CAPÍTULO 1
Tecnologia da informação,
governança de TI e introdução
ao gerenciamento de projetos
TECNOLOGIA DA INFORMAÇÃO
Conceito de tecnologia da informação
Em geral, a coleção de sistema de computação utilizada por uma empresa é consi-
derada tecnologia da informação. Um dos objetivos da tecnologia da informação é
dar suporte às operações das organizações, sejam elas privadas ou públicas, e na
maioria dos setores. O motivo para esse uso generalizado da TI é porque ela se tor-
nou o principal facilitador das atividades empresariais no mundo de hoje. A TI tam-
bém é um catalisador de mudanças fundamentais na estrutura, nas operações e no
gerenciamento das organizações, devido às seguintes capacidades (Turban, 2005):
Realizar cálculos numéricos de alta velocidade e de grande volume.

Oferecer comunicação rápida, precisa e pouco dispendiosa dentro e entre as
organizações.
Automatizar ambos os processos comerciais semi-automáticos e as tarefas ma-
nuais.
Armazenar grandes quantidades de informação em um espaço fácil de acessar,
embora pequeno.
Permitir o acesso rápido e pouco dispendioso a grandes quantidades de infor-
mação, no mundo inteiro.
Facilitar a interpretação de grandes quantidades de dados.
Permitir a comunicação e a colaboração em qualquer lugar, a qualquer momento.

4 GERENCIAMENTO DE PROJETOS DE TECNOLOGIA DA INFORMAÇÃO
Aumentar a eficácia e a eficiência das pessoas trabalhando em grupos em um só

lugar ou em vários locais diferentes.
Facilitar o trabalho em ambientes perigosos.
A TI e os departamentos da empresa
Independentemente da área funcional, os gerentes utilizam a tecnologia da informa-
ção como uma arma competitiva. É interessante, devido à magnitude de muitas deci-
sões estratégicas, que todas as áreas funcionais normalmente trabalhem juntas para
oferecer entrada para uma decisão.
Para o departamento de finanças e contabilidade

Considere a abertura de uma nova fábrica em outro país, claramente uma decisão es-
tratégica. Os gerentes de finanças e contabilidade utilizam a TI para calcular e anali-
sar o investimento, prever receitas e atividade de negócios, determinar as melhores
fontes e usos de fundos (por exemplo, taxas de câmbio de moeda), gerenciar o fluxo
de caixa e outros recursos financeiros, e realizar auditorias contínuas para garantir
que o conceito seja fundamentalmente sadio e que todos os relatórios e documentos
financeiros sejam exatos.
Para o departamento de marketing

Os gerentes de marketing utilizam a TI para realizar a análise de site (determinar o
melhor local para as instalações), determinar os melhores canais de propaganda nes-
se país e definir preços de produto. Os gerentes de marketing também gerenciam o
relacionamento com o cliente, o que ocasiona um conhecimento profundo da lin-
guagem cultural local.
Para o departamento de gerenciamento de produção/operações

Os gerentes de produção/operação utilizam a TI para processar pedidos do cliente,
desenvolver agendas de produção, controlar níveis de estoque e monitorar a qualida-
de do produto. Eles são responsáveis por projetar a nova planta e seus produtos e,
depois, pelas operações reais de manufatura (Computer-Aided Design, Compu-
ter-Assisted Manufacturing, Computer-Integrated Manufacturing – CAD/CAM/
CIM). Além disso, utilizam a TI para gerenciar a cadeia de fornecimento, que será
uma operação mais complexa porque é internacional.
Para o departamento de gerenciamento de recursos humanos

Os gerentes de recursos humanos utilizam a TI para filtrar candidatos a emprego, ad-
ministrar testes de desempenho aos funcionários e monitorar a produtividade dos
funcionários. Eles também usam a TI para produzir garantias de evicção e desenvol-
ver importantes documentos e relatórios legais.

TECNOLOGIA DA INFORMAÇÃO, GOVERNANÇA DE TI E INTRODUÇÃO AO GERENCIAMENTO...
CAPÍTULO 1 5
Esses são apenas alguns exemplos dos papéis da TI nas diversas áreas funcionais de
uma organização. É importante que os estudantes dessas várias áreas funcionais co-
nheçam a importância dos sistemas de informação em seus campos específicos (Tur-
ban, 2005).
Tecnologia e economia
Todas as organizações – com fins lucrativos, sem fins lucrativos, setor privado, setor
público – no século XXI operam na economia digital, que é uma economia baseada
em tecnologias digitais, incluindo redes de comunicações digitais (a Internet, intra-
nets, redes de valor agregado privadas ou VANs e extranets), computadores, soft-
ware e outras tecnologias de informação relacionadas. A economia digital às vezes
também é chamada de ecomomia da Internet, a nova economia ou economia da Web
(Turban, 2005).
Nessa nova economia, as redes digitais e as infra-estruturas de comunicações ofe-
recem uma plataforma global sobre a qual as pessoas e organizações interagem, se
comunicam, colaboram e buscam informações. Essa plataforma inclui, por exemplo
(Choi e Whinston, 2000):
Um grande conjunto de produtos digitalizáveis (produtos que podem ser con-

vertidos para o formato digital) – bancos de dados, notícias e informações, li-
vros, revistas, programação de televisão e rádio, filmes, jogos eletrônicos, CDs
de música e software – que é transportado pela infra-estrutura digital, a qual-
quer momento, em qualquer lugar do mundo.
Consumidores e firmas especializadas que realizam transações financeiras digi-
talmente – por meio de moedas digitais ou tokens financeiros transportados
por computadores em rede e dispositivos portáteis.
Bens físicos como aparelhos eletrodomésticos e automóveis que possuem mi-
croprocessadores e capacidade de rede embutidos.
O termo economia digital também se refere à convergência de tecnologias de com-

putação e comunicações na Internet e em outras redes, e o fluxo resultante de informa-
ções e tecnologia que está estimulando o comércio eletrônico e uma grande mudança
organizacional. Essa convergência permite que todos os tipos de informação (dados,
áudio, vídeo, imagens) sejam armazenados, processados e transmitidos por redes para
muitos destinos no mundo inteiro. A economia digital ajudou a criar uma revolução
econômica, que foi evidenciada pelo desempenho econômico sem precedentes e por
um longo período de expansão econômica contínua (de 1991 até 2000).
A TI e as pressões do mercado
O ambiente empresarial é uma combinação de fatores sociais, econômicos, físicos e
políticos que afetam as atividades da empresa. Mudanças significativas em qualquer

um desses fatores provavelmente criarão pressões comerciais sobre as organizações.

Estas normalmente respondem a essas pressões com atividades suportadas pela TI.
As organizações sofrem normalmente três tipos de pressões: mercado, tecnologia e
pressões sociais (Turban, 2005).
As pressões do mercado vêm da economia global e da forte competição, da natu-
reza mutável da força de trabalho e de clientes poderosos. Uma pressão importante
que existe para as empresas em um mercado global é o custo de mão-de-obra, que
varia bastante entre os países. Em geral, os custos da mão-de-obra são maiores em
países desenvolvidos do que em países em desenvolvimento. Além disso, os países
desenvolvidos normalmente pagam altos encargos aos funcionários, o que torna o
custo de realização de negócios ainda mais caro. Portanto, muitos setores com uso
intenso de mão-de-obra passaram suas operações para países com baixos custos de
mão-de-obra. Essas mudanças são bastante facilitadas pela TI. Baixos custos de
mão-de-obra tornam firmas chinesas atraentes como parceiros em esforços de ma-
nufatura conjuntos. A força de trabalho, particularmente nos países desenvolvidos,
está se tornando mais diversificada, à medida que cada vez mais mulheres, pais soltei-
ros, minorias e pessoas com deficiências trabalham em todos os tipos de cargos. A TI
está facilitando a integração dessa grande variedade de funcionários para a força de
trabalho tradicional e também está permitindo que as pessoas trabalhem em casa
(home office). A sofisticação e as expectativas dos consumidores aumentam à medi-
da que estes se tornam mais conhecedores da disponibilidade e da qualidade de pro-
dutos e serviços. Na Internet, os clientes agora podem facilmente encontrar infor-
mações detalhadas sobre produtos e serviços, comparar preços e comprar em leilões
eletrônicos. Os clientes hoje desejam produtos e serviços customizados, com alta
qualidade e preços baixos. A importância dos clientes forçou as organizações a au-
mentarem seus esforços para adquirir e reter os clientes. O esforço de toda a empre-
sa para fazer isso é denominado gerenciamento de relacionamento com o cliente
(CRM – Customer Relationship Management) (Turban, 2005).
A segunda categoria de pressões de negócios consiste nas pressões relacionadas à
tecnologia. Duas pressões importantes são a inovação tecnológica e a sobrecarga
de informações. Em relação à inovação e obsolescência tecnológica, as tecnologias
novas e melhoradas rapidamente criam ou dão suporte a substitutos para produtos,
opções de serviço, alternativas e qualidade surpreendente. Como resultado, os
melhores produtos de hoje podem estar obsoletos amanhã. A tecnologia que mais
contribuiu para essa pressão é a tecnologia de informação baseada na Web. Em re-
lação à sobrecarga de informações, a quantidade de informações disponíveis na
Internet mais do que duplica a cada ano, e grande parte dela é gratuita. A Internet e
outras redes de telecomunicações estão levando uma enxurrada de informações
aos gerentes. Portanto, a acessibilidade, a navegação e o gerenciamento de dados,
informações e conhecimento, que são necessários para a tomada de decisão da ge-
rência, são críticos. As únicas soluções eficazes são fornecidas pela tecnologia da

CAPÍTULO 1 7
informação (por exemplo, mecanismos de busca, bancos de dados inteligentes e

data mining) (Turban, 2005).
A terceira categoria de pressões de negócios consiste nas pressões relacionadas à socie-
dade. Elas incluem responsabilidade social, regulamentação/desregulamentação do go-
verno, gastos com programas sociais, gastos com proteção contra terrorismo e questões
éticas. As questões sociais que afetam os negócios vão desde o estado do ambiente físico
até as contribuições das empresas com educação (por exemplo, permitindo que os esta-
giários trabalhem nas empresas). Algumas corporações desejam gastar tempo e/ou di-
nheiro solucionando diversos problemas sociais. Um problema social é a exclusão digital,
o que significa que, entre os países e entre diferentes grupos de pessoas dentro dos países
existe uma grande divisão entre aqueles que têm acesso à tecnologia da informação e a
comunicações, e as utilizam com eficiência, e aqueles que não possuem isso, por não
terem condições de investir em hardware e software para terem acesso a essas informações,
tecnologias e facilidades da modernidade. Outras pressões de negócios estão relaciona-
das a regulamentações do governo referente a saúde, segurança, controle ambiental e
oportunidades iguais. As regulamentações do governo normalmente são vistas como res-
trições dispendiosas sobre os negócios. Em geral, a desregulamentação do governo in-
tensifica a competição. No Capítulo 4 veremos um exemplo desse tipo de regulamenta-
ção aplicada à TI. Desde 11 de setembro de 2001, as organizações têm estado sob uma
forte pressão para se protegerem contra ataques terroristas. A TI pode contribuir na área
de proteção, oferecendo sistemas de segurança e, possivelmente, identificando padrões
de comportamentos que ajudarão a prevenir ataques terroristas (incluindo cyberataques)
contra as organizações. A ética se relaciona aos padrões de certo e errado, e a ética da in-
formação relaciona-se aos padrões de certo e errado nas práticas de processamento de in-
formações. As questões éticas são muito importantes porque, se tratadas de modo inefi-
caz, têm o poder de danificar a imagem de uma organização e destruir a moral dos funcio-
nários. O uso da TI levanta muitas questões éticas, desde a monitoração de e-mail até a
invasão em potencial da privacidade de milhões de clientes cujas informações são arma-
zenadas em bancos de dados privados e públicos (Turban, 2005).
As pressões sobre as organizações estão aumentando, exigindo que estas estejam
preparadas para ações responsivas se desejarem ter acesso. Essas respostas organiza-
cionais estão divididas em sete categorias conforme detalhadas na obra de Turban,
Administração de Tecnologia da Informação: Teoria e Prática:
Sistemas estratégicos
Foco no cliente
Melhoria contínua
Reestruturação dos processos de negócios
Pedido por encomenda e customizações em massa
Aliança de negócios
Negócios eletrônicos e e-commerce

Planejamento dos sistemas de informação

Há muito tempo, uma das principais preocupações da gerência dos departamentos de sis-
temas de informação é o aperfeiçoamento do processo de planejamento. O planejamen-
to básico dos sistemas de informação trata das seguintes questões gerais (Turban, 2005):
1. Alinhar o plano de TI com o plano de negócio da empresa. A primeira tarefa

da TI é identificar aplicativos de sistemas de informação que se adaptem aos
objetivos e às prioridades estabelecidas pela organização. A surpresa é que as
estratégias e os planos organizacionais muitas vezes não estão disponíveis
por escrito ou não foram formulados em termos adequados ao planejamento
de TI. Por isso, às vezes, é difícil avaliar as estratégias e as metas às quais o
plano de TI deve se alinhar.
2. Desenhar uma arquitetura de TI para a empresa de forma que os usuários,
os aplicativos e os bancos de dados possam ser integrados e colocados jun-
tos em rede. Refere-se à estrutura geral (de alto nível) de todos os siste-
mas de informação de uma empresa. Essa estrutura consiste em aplicativos
de diversos níveis gerenciais e aplicativos voltados para diversas atividades
funcionais e operacionais, tais como marketing, P&D, produção e distri-
buição. A arquitetura da informação também inclui infra-estrutura de
banco de dados, software de apoio e as redes necessárias para interligar os
aplicativos. A arquitetura de informação de uma organização deveria mo-
delar um desenvolvimento de longo prazo e permitir respostas rápidas às
diversas demandas de curto prazo dos sistemas de informação e das neces-
sidades dos usuários.
3. Alocar de forma eficiente, entre aplicativos concorrentes, os recursos ope-
racionais e de desenvolvimento de sistemas de informação. É bastante com-
plicado fazer uma alocação racional e otimizada dos recursos para sistemas
de informação entre diversas unidades de uma empresa, principalmente se a
carteira de aplicativos em potencial não se articular como o plano geral da
empresa e se as necessidades das unidades funcionais e organizacionais não
estiverem integradas em uma estrutura de planejamento que estabeleça pra-
zos e prioridades.
4. Planejar os projetos de sistemas de informação de modo que possam ser
concluídos dentro do prazo e do orçamento e incluam as funcionalidades es-
pecificadas. Muitos grandes projetos de TI não são considerados dentro do
prazo e do orçamento estipulados. É comum ouvir-se na área de TI que os
projetos normalmente “levam o dobro de tempo e custam quatro vezes
mais” do que o inicialmente planejado. Isso prejudica o desempenho da em-
presa e a credibilidade da gerência do departamento de sistema de informa-
ção. Raramente os planos de projetos são precisos, pois o tempo exato e as
necessidades de recursos em geral são subestimados. Muitas vezes, devido à

CAPÍTULO 1 9
pressão para terminar um projeto dentro do prazo e do orçamento, certas

características prometidas são abandonadas. Essa redução de ficcionalidade
e/ou qualidade freqüentemente leva à insatisfação dos usuários com os sis-
temas resultantes. Essas características que faltam ou não são adequadas te-
rão de ser acrescentadas posteriormente, durante a “manutenção do siste-
ma”. Certamente, um planejamento de projeto mais cuidadoso poderia evi-
tar o impacto dos problemas.
Um modelo de planejamento de TI
Diversos modelos foram desenvolvidos para facilitar o planejamento de TI (Ward e
Griffiths, 1996; Casidy, 1998; Papp, 2001). O modelo de quatro etapas de Wether-
be (1993) é bastante interessante. Esse modelo consiste em quatro atividades princi-
pais: planejamento estratégico, análise de requisitos, alocação de recursos e planeja-
mento de projeto.
Planejamento estratégico de TI: estabelece a relação entre o plano geral da em-

presa e o plano de TI. A seqüência de ações deverá ser a seguinte: definir a mis-
são do sistema de informação, avaliar o ambiente, avaliar os objetivos e estraté-
gias da empresa, definir as políticas, os objetivos e as estratégias do sistema de
informação, avaliar as necessidades de informação da empresa, montar o plano
mestre de desenvolvimento, desenvolver plano de necessidades de recursos,
avaliar o projeto e desenvolver os planos do projeto.
Análise de requisitos de informação: identifica as necessidades mais abrangen-
tes de informação da empresa, para determinar a arquitetura de informação es-
tratégica que pode ser usada para dirigir o desenvolvimento de aplicativos espe-
cíficos. Nessa atividade é necessário definir subsistemas organizacionais subja-
centes, desenvolver uma matriz de subsistemas, definir e avaliar as necessida-
des de informação para os subsistemas organizacionais, definir as categorias
principais de informação e inserir nelas os resultados da entrevistas e desenvol-
ver a matriz informação/sistema.
Alocação de recursos: aloca os recursos para o desenvolvimento de aplicativos
de TI e os recursos operacionais. Consiste no desenvolvimento de hardware,
software, comunicação de dados, instalações, pessoal e planos financeiros ne-
cessários para executar o plano-mestre de desenvolvimento, como definido na
análise de necessidades. Essa fase fornece a estrutura para a aquisição de tecno-
logias e mão-de-obra e identifica os recursos financeiros necessários para pro-
porcionar níveis adequados de serviços (SLAs) para os usuários.
Planejamento de projeto: desenvolve um plano que delineia o cronograma e as
necessidades de recursos para projetos específicos de sistema de informação.
Fornece uma estrutura geral dentro da qual pode ser planejado, programado e
controlado o desenvolvimento dos aplicativos específicos.

Método PPTI – Priorização de Projetos de Tecnologia da Informação1

Introdução
Há diversas técnicas para avaliação individual de projetos descritas na literatura e
aplicadas no dia-a-dia das organizações, mas as empresas ainda têm dificuldades
quando é necessário avaliar um grande conjunto de projetos em carteira e definir ra-
pidamente a prioridade de cada um deles.
Especialmente na área de Tecnologia da Informação, onde muitos projetos têm
sido iniciados para dar suporte aos objetivos estratégicos do negócio, faz-se necessá-
rio adotar um método que seja simples e efetivo na definição de uma lista priorizada
de projetos a executar.
Este capítulo trata das características desejáveis para esse método e de uma expe-
riência empresarial com a criação e o uso do método PPTI (Priorização de Projetos
de Tecnologia da Informação).
Diante das intensas e velozes mudanças que ocorrem no ambiente econômico,
as empresas procuram garantir sua sobrevivência por meio de inúmeros projetos
lançados como tentativa de resposta às pressões e ondas tecnológicas de direções
diversas.
Normalmente, a quantidade desses projetos é muito grande, e os investimentos e
recursos necessários para sua realização são altos. Nem sempre esse grande volume
de projetos é priorizado e, conseqüentemente, não é empreendido e gerenciado de
modo a obter efetivamente o posicionamento estratégico e as vantagens competiti-
vas desejadas pela empresa.
O grande problema então é que se corre o risco, com o passar do tempo, de se in-
vestir recursos no gerenciamento detalhado e completo de projetos que não são es-
trategicamente importantes, deixando-se de dar o acompanhamento devido aos
projetos que deveriam ser tratados de forma mais cuidadosa.
Quando o projeto não é gerenciado no nível adequado, temos algumas distorções
possíveis:
Os impactos do gerenciamento em nível inadequado dos projetos de alta com-
plexidade e importância, tais como atrasos por dificuldades na tomada de deci-
sões, determinações erradas ou desalinhadas em relação à estratégia da empre-
sa, retrabalhos devido à falta de visão corporativa, aumento da probabilidade
dos riscos do plano etc.
Provável aumento do custo total de gerenciamento, já que haverá mais projetos
sendo gerenciados pela alta direção, onde o custo unitário de gerenciamento é
mais alto.
Risco de decisões inadequadas em programas que, pela sua importância, defi-
nem o futuro da organização.
1Colaboração: Professor Fernando Carvalho.

CAPÍTULO 1 11
As técnicas de seleção e priorização de projetos são fartamente abordadas na lite-

ratura existente, mas normalmente são mais adequadas à análise comparativa de uma
pequena quantidade. Este artigo relata a utilização do método PPTI – Priorização de
Projetos de Tecnologia da Informação – desenvolvido e aplicado junto a alguns de-
partamentos de uma organização do setor privado nacional para criar, selecionar e
priorizar os projetos de seus respectivos portfolios junto à área de TI dessa empresa.
O método foi desenvolvido com base na experiência profissional de um grupo de
analistas da empresa.
O problema da administração do portfolio de projetos

O gerenciamento de portfolio é um processo de decisão dinâmico através do qual
uma lista de projetos para novos produtos (e para Pesquisa & Desenvolvimento) é
constantemente atualizada e revisada.
Neste processo, novos projetos são avaliados, selecionados e priorizados; os exis-
tentes podem ser acelerados, eliminados ou “despriorizados”; e recursos são aloca-
dos e realocados aos projetos ativos. O processo de decisão de portfolio é caracteri-
zado por informações incertas e mutáveis; oportunidades dinâmicas, múltiplos obje-
tivos e considerações estratégicas, interdependência entre projetos e múltiplas deci-
sões e localidades (COOPER, EDGETT e KLEINSCHMIDT, 2001).
Modelos de portfolio (ou carteira de projetos) são justificáveis apenas em casos
onde há concorrência pelos mesmos recursos. A administração decidirá como alocar
os recursos aos projetos do portfolio conforme as características peculiares da orga-
nização que os patrocina (SHTUB, BARD e GLOBERSON, 1994). Normalmente, a
demanda por recursos é maior do que a sua disponibilidade.
O método de priorização de projetos deve contemplar algumas necessidades das
organizações, resumidas pelos requerimentos abaixo:
A estratégia competitiva da organização precisa ser considerada e refletida na

lista de prioridades dos projetos.
A importância de cada projeto deve ser explicitada de forma clara, pois o nível
de esforço para o gerenciamento de tal projeto deve ser proporcional à sua priori-
dade estratégica.
O processo de priorização precisa ser flexível e refletir o dinamismo das mu-
danças nos planos da organização.
O processo de priorização deve ser simples e rápido, a fim de viabilizar sua utili-
zação com grandes quantidades de projetos.
As sinergias positivas e negativas entre os projetos devem ser consideradas.
As técnicas convencionais de avaliação de projetos

As técnicas normalmente discutidas (Moraes Filho e Weinberg, 2000) para a seleção
e priorização dividem-se nas seguintes categorias: qualitativas (informação menos

acurada e foco de análise mais amplo); semiquantitativas e quantitativas (informação

mais acurada e foco de análise mais estreito).
A utilização de cada uma delas dependerá, em grande parte, do estágio de maturi-
dade em que se encontram os projetos a serem analisados e a quantidade e qualidade
de informações disponíveis sobre eles.
Numa pesquisa realizada entre 51 indústrias da região Sudeste do Brasil (KRU-
GLIANSKAS, 1987), constatou-se que, dentre os critérios para seleção de projetos
de P&D adotados pelas empresas, destacam-se como mais importantes:
a. Compatibilidade com a estratégia global da empresa.

b. Identificação com uma clara necessidade de mercado.
c. Potencialidade de retorno, em termos de receita de vendas.
d. Possibilidade de proporcionar à empresa vantagens competitivas no seu
mercado.
e. Utilização de uma classificação (GIBSON, citado por MORAES FILHO e
WEINBERG, 2000) que parte das técnicas puramente intuitivas às altamen-
te quantitativas e analíticas.
f. Ordenamento – comparação dos projetos aos pares, de forma intuitiva.
g. Pontuação (scoring) – uso de um conjunto de critérios explícitos com ou sem
ponderação. Os projetos são classificados segundo o total de pontos obtidos
somando-se as notas em todos os critérios.
h. Análise de risco – uso de índices de probabilidade para apuração do risco
(técnico, comercial e econômico) em relação ao quociente benefício/custo.
i. Pontuação por índices econômicos – uso de índices como TIR (Taxa Interna
de Retorno), VPL (Valor Presente Líquido), VPLU (Valor Presente Unitá-
rio), Payback (Tempo de retorno do investimento), Relação Benefício-
Custo, etc. calculados a partir do fluxo de caixa de cada projeto.
j. Métodos formais de otimização – uso de rotinas de programação linear ou
similares para selecionar a alternativa que maximiza uma função lucro a par-
tir de modelos de cada projeto.
Ao verificar a lista de requerimentos anteriormente descrita, nota-se que os tipos

de métodos citados não atendem completamente às necessidades identificadas. A
maioria dos métodos, por exemplo, trará dificuldades operacionais de aplicação nos
casos em que houver uma grande quantidade de projetos em portfolio. Outros não
consideram adequadamente a questão estratégica na priorização dos projetos. Ou-
tros ainda, mesmo sendo quantitativamente muito objetivos, trazem diversas des-
vantagens dependendo da técnica empregada (CONTADOR, 1981).
O método adotado no caso relatado é do tipo Pontuação e decidiu-se executar al-
guns ajustes específicos, conforme será descrito a seguir.

CAPÍTULO 1 13
1. Priorização estratégica de projetos

Um bom método de priorização deve considerar as definições fundamentais do pla-
nejamento estratégico empresarial (Visão, Missão etc.).
No caso da Tecnologia da Informação, os projetos realizados também são decor-
rentes de um desdobramento da estratégia. A Visão será alcançada através da execu-
ção efetiva da Missão, esta será possível através da implementação das estratégias e
do alcance dos objetivos estratégicos propostos. Os objetivos e as estratégias depen-
dem, para seu sucesso, dos Fatores Críticos identificados. Estes, por sua vez, serão
traduzidos em Necessidades de Informação a serem supridas através de Sistemas de
Informação, desenvolvidos através de Projetos de TI (RODRIGUEZ e FERRANTE,
1995).
Conforme MAXIMIANO (1997, p. 20): “Projetos são empreendimentos finitos,
que têm objetivos claramente definidos em função de um problema, oportunidade
ou interesse de uma pessoa ou organização.” Quando se procura definir quais são os
mais prioritários, é fundamental que os objetivos, interesses e oportunidades atendi-
dos por cada um sejam explicitados e confrontados com os objetivos, interesses e
oportunidades do negócio da organização como um todo, a fim de definir, por esta
análise, sua importância estratégica.
Complexidade
do Projeto
Alta
A C
Baixa
B D
Baixa Alta Importância do Projeto
F I G U R A 1 . 1 Tipos de projetos segundo sua importância e complexidade
Por outro lado, não basta a definição clara da importância estratégica de um projeto
para garantir que sejam escolhidas as técnicas mais adequadas ao seu gerenciamento. O
outro vetor fundamental nessa análise é a complexidade do projeto. Os complexos
exigirão controles e freqüências de acompanhamento muito diferentes dos simples.
Por esses motivos, é recomendável apoiar o método de priorização de portfolio
de projetos em ambos os vetores: Importância estratégica e Complexidade. Na Figu-
ra 1.1 estão ilustrados quatro quadrantes definidos pela aplicação desses vetores.

Projetos do tipo A – são aqueles com alta importância e complexidade. Estarão situa-
dos neste quadrante os maiores desafios em termos de transformação organizacional.
Projetos do tipo B – também são muito importantes, porém com menor comple-
xidade de execução. São os que podem agregar valor à organização com um nível
menor de esforço.
Projetos do tipo C – altamente complexos e sem muita importância estraté-
gica para a organização. Normalmente incluem-se aqui os com viabilidade eco-
nômica baixa ou inexistente, como aqueles iniciados por exigência legal, por
exemplo.
Projetos do tipo D – são, na verdade, iniciativas ou idéias de menor importância
transformadas em projetos e estacionadas no portfolio de projetos à espera da dispo-
nibilidade de recursos ou de oportunidades técnicas para sua realização.
O grau de profundidade que será adotado para execução de cada processo de Ge-
renciamento de Projetos deve variar conforme o tipo de projeto gerenciado, segun-
do a metodologia adotada.
2. Caso prático: Priorização de projetos de TI

No caso da empresa analisada, o método de priorização aplicado envolveu desde a di-
retoria do departamento até o pessoal de linha (tanto do lado do negócio quanto das
equipes de execução). O método adotado inclui os seguintes passos:
Revisão da Orientação Estratégica

O que é feito Como é feito
Define-se com a liderança do Através de um workshop de planejamento

departamento (diretorias e gerência) a estratégico, utilizando as técnicas e ferramentas
Visão e Missão do departamento. Se o próprias das reuniões JAD (Joint Application
departamento já possui essas definições Design).
estratégicas, faz-se uma revisão e
atualização delas.
Análise de Ambiente
Faz-se a análise ambiental do negócio Através de um workshop de planejamento

(SWOT Analysis), discutindo-se estratégico, utilizando as técnicas e ferramentas
variáveis internas (Pontos Fortes e próprias das reuniões JAD.
Fracos) e externas (Oportunidades e
Ameaças).

CAPÍTULO 1 15
Definição de Objetivos Estratégicos
O Que é Feito Como é Feito
Define-se o conjunto de grandes No workshop de planejamento estratégico, os
objetivos que o departamento pretende objetivos são definidos e confrontados com a análise
alcançar nos próximos anos ou meses, de ambiente realizada a fim de aumentar sua
em coerência com as definições obtidas consistência. É feito um cruzamento entre objetivos e
nos itens anteriores. ambiente, que possibilita, inclusive, a discussão da
existência de alguma priorização entre os objetivos
ou a necessidade da criação de novos objetivos que
abordem pontos fracos ou fortes, ameaças ou
oportunidades não contempladas. Da mesma forma,
pode-se questionar objetivos que não estejam
vinculados a algumas forças ambientais.
Definição da complexidade dos Projetos de TI
Uma revisão de cada projeto de TI Através de entrevistas com os responsáveis por cada
existente no “backlog” de projetos do projeto junto ao departamento. A métrica de definição
departamento, verificando a atualidade de complexidade utiliza sete informações fornecidas
da necessidade e definindo sua acerca de cada projeto e define a complexidade,
complexidade. quantificando-a em um número entre 1% e 100%
(relativos à complexidade máxima possível).
Definição da Importância Estratégica dos Projetos de TI
Para cada projeto do portfolio, Numa reunião estruturada, com as gerências e técnicos
verifica-se a intensidade com que se do departamento envolvido, os projetos são
estima que ele ajudará o departamento a confrontados com os objetivos estratégicos e os
alcançar cada objetivo estratégico. participantes refletem sobre o grau em que o projeto
auxiliará a organização a alcançar seus objetivos. Serão
mais prioritários quanto mais intensamente apoiarem os
objetivos definidos.
Ajuste do portfólio de projetos
A matriz é checada para identificar Logo após o cruzamento Projetos versus Objetivos,
eventuais problemas. verifica-se se há algum projeto que não apóia a realização
de nenhum objetivo, tendo baixíssima prioridade. Isso
pode se dever à falta de objetivos importantes que não
foram mencionados pelos participantes ou simplesmente
à ausência de importância do projeto, neste caso,
discute-se o seu cancelamento. Também poderão
ocorrer objetivos sem nenhum projeto ou com apoio
insuficiente de projetos para sua consecução. Pode-se,
então, estruturar e priorizar novos para garantir o
atendimento desses objetivos estratégicos.

Mudança do processo de criação e seleção de projetos

O processo de registro e controle de As atividades de priorização individual de projetos
projetos no departamento é alterado a são inseridas no fluxo do processo, os sistemas ou
fim de permitir a definição de planilhas de controle são ajustados e as pessoas são
importância e complexidade a cada novo treinadas para aplicação das métricas. Normalmente
plano inserido no portfolio. essa atividade, por exigir mais tempo, é iniciada antes
da realização dos workshops para garantir que o novo
processo esteja implantado assim que o portfolio tiver
sido priorizado. Caso contrário, todo o trabalho de
priorização pode ser perdido depois de algumas
semanas de manutenção no portfolio de projetos.
3. Vantagens e limitações do modelo utilizado

Por mais aplicável e adequado que seja o método para o caso citado, é importante fa-
zer uma análise crítica de suas possibilidades.
Desvantagens do método
A definição dos critérios de classificação é subjetiva. Mesmo partindo da Visão e
Missão do negócio analisado, não há garantia total de que todos os objetivos es-
tratégicos importantes para o departamento sejam relacionados pelos partici-
pantes dos workshops.
Alteração no processo. A “fotografia” do portfolio tirada através do método
pode rapidamente desvanecer caso o processo de manutenção de projetos não
seja alterado e implantado de forma sincronizada com a aplicação do método.
Evidentemente essa desvantagem não é restrita a esse método, mas é uma exi-
gência a qualquer iniciativa de priorização contínua da carteira de projetos.
Como a natureza do processo de seleção e priorização de projetos é muito dinâmica, a
filtragem, a avaliação e as decisões acerca da carteira de projetos precisam ser repeti-
das periodicamente em função das mudanças no contexto estratégico do negócio.
Disponibilidade dos executivos. A presença da liderança do departamento nos
workshops é indispensável, e esse espaço de tempo está cada vez mais difícil de
ser obtido na agenda dos executivos.
Problemas de avaliação. Como o método não verifica quantitativamente a re-
lação de benefícios e custos de cada projeto, poderá indicar como prioritários
os que não tragam lucratividade à empresa. Para os que exigirem maiores in-
vestimentos, não se podem descartar análises suplementares de viabilidade
econômica.
O modelo não leva em conta, de forma objetiva, o status de cada projeto anali-
sado. Definir a prioridade sem considerar esse aspecto pode trazer problemas
na administração de tais projetos. Apesar dos participantes do workshop consi-

CAPÍTULO 1 17
derarem essa informação de forma subjetiva, o modelo deveria explicitá-la para

um melhor desempenho.
Vantagens e benefícios do método
Comprometimento. Obter uma lista de prioridades para os projetos de um depar-
tamento não é tarefa simples. Quando essa lista é exaustivamente discutida e
acordada entre as várias diretorias e gerências do departamento, tem-se um
consenso fundamental para a aplicação dos recursos aos projetos de forma mais
tranqüila, evitando inúmeros conflitos de alocação e de atendimento aos depar-
tamentos pelas áreas que lhes prestam serviços.
Foco. Permite calibrar os esforços de execução e gerenciamento conforme o ní-
vel de importância e complexidade de cada projeto.
Padronização e Abrangência. Pode-se tratar de todos os projetos do departamento
através da identificação de importância e complexidade. Pode-se também ex-
trapolar, a partir da identificação da importância estratégica de cada departa-
mento para a organização, o conjunto de projetos priorizados da carteira da
empresa como um todo.
Tempo. O método é muito rápido para peneirar projetos indesejáveis e criar no-
vos e necessários.
Independência. O método possibilita à área de negócios definir sua visão sobre a
prioridade dos projetos de TI, independentemente de uma avaliação que consi-
dere os interesses das áreas técnicas. Uma vez definidos os projetos prioritá-
rios, estratégias diferentes de execução podem ser adotadas, inclusive a tercei-
rização de alguns projetos. De qualquer forma, as áreas técnicas sempre pode-
rão sugerir ajustes na prioridade definida a fim de obterem ganho de escala na
execução dos que envolvam módulos similares dos sistemas.
Conclusões
O PPTI tem se mostrado um método muito interessante em suas aplicações no ambi-
ente interno da empresa analisada. Desde sua forma de aplicação mais simples até o
formato em que se encontra atualmente, já foi aplicado em quatro grandes departa-
mentos, possibilitando ganhos tangíveis e intangíveis, pois a simples discussão con-
junta dos projetos e de sua importância já permite às pessoas que conduzem o negó-
cio uma visibilidade maior das iniciativas em andamento para que o suporte de TI ao
seu negócio seja mais adequado. Esse conhecimento é fundamental para que os ges-
tores possam realmente exercer uma administração estratégica de seu negócio, a
partir dos rumos definidos em seu planejamento estratégico.
O método continua em constante aprimoramento, sendo que algumas iniciativas de
pesquisas posteriores merecem ser destacadas: há necessidade de verificação da métri-
ca de complexidades, que foi definida empiricamente, a fim de determinar se a hipóte-
se adotada para explicação da complexidade dos projetos a partir das variáveis escolhi-
das é estatisticamente adequada ou se há itens a eliminar ou a incluir na métrica.

Um método de gerenciamento de portfolio pode ser considerado bom se gerar conjun-

tos de projetos com boa performance do ponto de vista de negócios (COOPER, EDGETT
e KLEINSCHMIDT, 1998). Uma avaliação mais completa do método utilizado poderá,
portanto, ser feita posteriormente para que sua completa efetividade seja comprovada.
Outro ponto que merece discussão é a definição das formas de gerenciar e condu-
zir projetos em cada um dos quadrantes definidos. Faz-se necessário adotar uma me-
todologia de gerenciamento e desenhar claramente os processos envolvidos e suas
variantes por nível de projeto.
Avançando no estudo e criação de métodos para gerenciamento de seus projetos,
as organizações realizarão e poderão utilizar seus recursos de forma mais efetiva e
obter os benefícios mais importantes para seu negócio.
Referências Bibliográficas
August, Judy H. JAD: Joint Application Design. São Paulo: Makron Books, 1993.
Carvalho, Fernando. Priorização da carteira de projetos: um método com uso do planejamento estratégico. São
Paulo: 2006.
Cassidy, A. A Practical Guide to IT Strategic Planning. Boca Raton, FL: CRC Press, 1998.
Choi, S. Y. e A. B. Whinston. The Internet Economy: Technology and Practice. Austin, TX: SmartEcon
Pub., 2000.
Contador, Cláudio Roberto. Avaliação Social de Projetos. São Paulo: Atlas, 1981, cap 2, pp. 37-54.
Cooper, Robert, EDGETT, Scott e KLEINSCHMIDT, Elko. Best Practices for Managing R&D
Portfolios. R&D Management, Oxford: Blackwell Publishers Ltd., pp. 20-33, julho e agosto
de 1998.
Cooper, Robert, EDGETT, Scott e KLEINSCHMIDT, Elko. Portfolio Management for New Produt De-
velopment: results of an industry practices study. R&D Management, Oxford: Blackwell Publishers
Ltd., n. 31., pp. 361-80, abril de 2001.
Gibson, John E. Managing Research and Development. Nova York: John Wiley & Sons, 1981, cap. 10.
Kruglianskas, Isak. Seleção, planejamento e controle de projetos de P&D: um estudo exploratório em empresas
brasileiras, 1987 (Tese de Livre Docência – Departamento de Administração da Faculdade de Economia,
Administração e Contabilidade da Universidade de São Paulo).
Locke, Christopher. O Manifesto da Economia Digital. Rio de Janeiro: Campus/Elsevier, 2000.
Maximiano, Antonio Cesar Amaru. Administração de Projetos: transformando idéias em resultados. São
Paulo: Atlas, 1997.
Moraes Filho, Cassiano A. e Weinberg, Georg Michael L. “Seleção de Projetos de P&D: uma aborda-
gem prática”. In: Anais do XXI Simpósio de Gestão da Inovação Tecnológica. São Paulo: Núcleo
PGT-USP, 2000.
Papp, R. Strategic Information Technology: Opportunities for Competitive Advantage. Hershey, PA: Idea
Group, 2001.
Rodriguez, Martius V. e FERRANTE, Agustín J. A Tecnologia de Informação e a Mudança. Rio de Janei-
ro: Infobook, 1995, pp. 309-13
Shapiro, Carl. A Economia da Informação. Rio de Janeiro: Campus/Elsevier, 1999.
Shtub, Avraham, BARD, Jonathan F. e GLOBERSON, Shlomo. Project Management: engineering,
technology, and implementation. Nova Jersey: Prentice-Hall, 1994, cap. 3, pp. 110-63.
Turban, Efraim. Administração de Tecnologia da Informação: teoria e prática/Efraim Turban, R. Kelly
Rainer, Richard E. Potter. Rio de Janeiro: Campus/Elsevier, 2005.
______. Information Technology for Management: Transforming Organizations in the Digital Economy, 5a
edição. Nova York: John Wiley & Sons, 2006.

CAPÍTULO 1 19
______. Information Technology for Management: Transforming Organizations in the Digital Economy, 4a
edição. Nova York: John Wiley & Sons, 2004.
______. Introduction to Information Technology, 3a edição. Nova York: John Wiley & Sons, 2005.
______. Tecnologia da Informação para Gestão. 3a edição/Efraim Turban, Ephraim MClean e Ja-
mes Wetherbe. Porto Alegre: Bookman, 2004.
Ward, J. and P Griffiths. Strategic Planning for Information System, 2a edição. Chichester: John Wiley &
Sons, 1996.
GOVERNANÇA DE TI*
Introdução
Cada vez mais temos ouvido o termo “Governança”, e a tendência é o aprofundamento
no tema. Na realidade, acionistas, financiadores, gestores etc. buscam minimizar seus
riscos, exigindo cada vez mais: prestação de contas (accountability), eqüidade e transpa-
rência nas operações e nos informes. Essas exigências sempre existiram, mas, em conse-
qüência dos escândalos financeiros da Enron e WorldCom e das novas situações impostas
pelos desafios globais do desenvolvimento sustentável, as empresas buscam uma forma
de otimizar esses fundamentos, compilando as melhores práticas existentes, implantan-
do-as e criando estruturas para sua manutenção e constante aprimoramento.
A Governança deve estar presente em toda a empresa, mas requer técnicas diferen-
tes para cada aplicação. Nessa linha inicia-se uma “especialização” no processo, cada um
buscando a proteção de sua área, de sua responsabilidade, mas todos buscando prote-
ger as empresas na redução de riscos operacionais, estratégicos, fraudes etc.
Dentre as “especializações” a área de TI – Tecnologia da Informação é uma das
mais atingidas, pois tecnologia está presente em todas as áreas e operações de uma
organização, seja de natureza estratégica ou operacional.
IT Governance: De onde veio, onde está e para onde vai

Cada vez que nos deparamos com um nome novo nos perguntamos se não se trata de
apenas mais um modismo, foram tantas siglas e nomes nos últimos tempos que é de
se esperar esse tipo de preocupação.
Na verdade IT Governance, ou Governança em TI, já existe há muito tempo, nas-
ceu junto com a TI, assim como o marketing nasceu com o comércio, muito antes de
ser chamado como tal.
Assim como nas ondas de gestão anteriores, a origem está na ameaça à razão fun-
damental do capitalismo, o retorno sobre o capital investido.
No início do século passado, quando da criação das grandes empresas, havia a figu-
ra do dono, que aportava o capital, próprio ou de terceiros, supervisionava pessoal-
mente a gestão de sua empresa, delegava autoridade e cobrava os resultados de seus
executivos, para garantir o retorno sobre o capital investido.
*Com a colaboração de Gianni Ricardi.

Com o passar do tempo as empresas tiveram suas ações em bolsas de valores e a fi-
gura do dono foi pulverizada, dando assim mais autonomia para os executivos e pou-
ca, para não dizer nula, intervenção, ou cobrança das responsabilidades por parte dos
proprietários.
Em 24 de outubro de 1929, dia conhecido como “quinta-feira negra”, houve a cri-
se na bolsa de Nova York, que fez muitas empresas simplesmente deixarem de exis-
tir de uma hora para outra e os seus acionistas, surpreendidos, perderem todo o capi-
tal investido.
Na segunda metade do século passado, o retorno sobre os investimentos dos acio-
nistas foi ameaçado pelos processos otimizados usados pelos japoneses, que invadi-
ram os mercados ocidentais com seus produtos, fazendo várias empresas fecharem
ou terem seus lucros seriamente comprometidos.
Já existia a American Society for Quality (ASQ)2 desde 1946, mas nesse novo contex-
to, lançou-se mão dos conhecimentos de administração, produção, logística, marke-
ting e outras disciplinas que juntas formaram as ondas de Reengenharia, Total Qua-
lity Management, CRM, ERP e outras, seguidas dos respectivos processos de certifi-
cações e premiações do tipo ISO 9000 ou Malcolm Baldrige National Quality Award
(PNQ no Brasil), para que a partir de padrões, processos e métricas bem definidas,
fosse possível assegurar o retorno sobre o capital investido nas empresas.
O setor financeiro mundial também se estruturou após a crise mundial do setor
dos anos 80 e 90, no sentido de dar mais segurança aos seus investidores. Em 1988, o
Banco de Compensações Internacionais formulou o primeiro acordo de capitais na
cidade suíça de Basiléia. Esse acordo foi recentemente modernizado com a inclusão
de novas práticas de gestão corporativa e batizado de Basiléia 2.
Em 1985 já havia sido criado o COSO, Committee of Sponsoring Organizations
of the Treadway Commission, uma organização que tem por objetivo aprimorar a
qualidade dos relatórios financeiros, a ética nos negócios, a efetividade dos controles
e a governança corporativa, visando garantir a continuidade das empresas e o retorno
sobre o investimento realizado.
Já existiam mecanismos de controle baseados na contabilidade e organizados des-
de 1887 por instituições como a AICPA – American Institute of Certified Public
Accountants, mas, a partir do senso de urgência gerado em 1929, a publicação dos
balanços e as auditorias foram intensificadas, como forma de assegurar que os fluxos
financeiros, ativos e passivos estavam coerentes com o retorno sobre o capital espe-
rado pelos acionistas.
No final do século passado um grande número de investidores aplicou seu capital
em tecnologia da informação, tivemos a bolha das empresas ponto com, que explo-
diu frustrando o retorno esperado desses investimentos em TI.
Mais recentemente tivemos a quebra da empresa de energia Enron, da Consulto-
ria Arthur Andersen e da WorldCom na área de telecomunicações, que levou o go-
2 Maiores detalhes no Capítulo 10.

CAPÍTULO 1 21
verno americano a elaborar a lei Sarbanes-Oxley em 2002, a qual responsabiliza os

gestores e pode condená-los a penas de até 20 anos no caso de fraude constatada,
além de obrigá-los a ressarcir os prejuízos causados aos acionistas.
A área de TI, que era vista como uma “caixa preta”, passou a representar um sério
risco ao retorno sobre o investimento, ou mesmo à continuidade das empresas. De-
vido à crescente dependência da Tecnologia da Informação na composição e susten-
tação dos produtos e serviços, e em função do interesse público, os problemas de
compliance estão sendo expostos em tempo real.
É nesse contexto que o COBIT, Control Objectives for Information and related
Technology, ganhou forças como referência para o alinhamento, a estruturação e o
controle do ambiente de TI.
Segundo o IT Governance Institute a IT Governance trata basicamente de:
Alinhamento e entrega de valor por parte da área de TI para o negócio.
Correta alocação e medição dos recursos envolvidos.
A mitigação dos riscos em TI.
O COBIT tem a sua base em 4 dimensões, 34 processos, fatores críticos de suces-
so, indicadores de performance, indicadores de resultado e 318 objetivos de contro-
les que procuram equacionar o ambiente de TI para atender aos requerimentos do
negócio relativos às informações.
O COBIT diz o que deve ser feito, os conceitos, metodologias e ferramentas de
mercado cuidam do como fazer, dentre as quais podemos citar o ITIL IT Infrastruc-
ture Library, Six Sigma, PMI, BSC, ISO 17799, CMM, Unified Process e Benchmar-
king, dentre outros. O retorno sobre o capital já teve seu foco direcionado para a
gestão e demonstração dos ativos, a gestão financeira orçamentária, a gestão dos pro-
cessos, dos clientes, das informações, e devemos ver em um futuro não distante esse
foco se direcionar para a gestão do conhecimento, assim que uma ameaça ao retorno
sobre o capital investido estiver fortemente associada ao fluxo do conhecimento nos
mercados.
COBIT: http://www.isaca.org/
COSO: http://www.coso.org
AICPA: http://www.aicpa.org/index.htm
Finanças, Administração e Contabilidade: http://www.anefac.com.br/
ITIL: http://www.itil.org/
Project Management Institute: http://www.pmi.org/info/default.asp
Six Sigma: http://www.sixsigma.org
Modelagem de Processos: http://www.idef.com
Tradutor Numérico: http://www.sigmark.com.br/
Balanced Scorecard: http://www.bscol.com/
Metodologia para sistemas: http://www.unifiedprocess.com
Segurança da Informação: http://www.securityreview.com.br/index.php#

Prêmio Baldridge: http://www.baldridge.org

Fundação para o Prêmio Nacional da Qualidade: http://www.fpnq.org.br
Sarbanes-Oxley: http://www.sox-online.com/
COBIT – estrutura do framework

De acordo com o IT Governance Institute, o COBIT é “uma estrutura de relações e
processos para dirigir e controlar o ambiente de TI para alcançar as metas da organi-
zação somando valor enquanto equilibra risco versus retorno sobre o investimento
em TI e seus processos”.
Essa estrutura trata a tecnologia da informação em quatro dimensões:
Planejamento e organização
Este domínio cobre estratégia e táticas e busca a identificação do modo que
pode contribuir para a melhor realização dos objetivos organizacionais. Além
disso, a realização da visão estratégica precisa de ser planejada, comunicada e
administrada para perspectivas diferentes. Finalmente, uma organização for-
mal como também infra-estrutura tecnológica devem ser instauradas.
Aquisição e implementação
Para que a TI seja percebida como estratégica, soluções de TI precisam ser iden-
tificadas, desenvolvidas ou adquiridas, como também implementadas e inte-
gradas no processo empresarial. Também mudanças e manutenções de siste-
mas existentes são cobertas por este domínio para ter certeza de que o ciclo de
vida é assegurado para esses sistemas.
Entrega e suporte
Este domínio trata da entrega dos serviços requeridos pelo negócio, providos pelas
operações tradicionais com segurança, aspectos de continuidade e treinamento.
Para entregar serviços, devem ser montados os processos de apoio necessários.
Este domínio inclui o processamento de dados através de sistemas de aplicações.
Monitoramento
Todo processamento precisa ser avaliado regularmente para assegurar a qualida-
de e compliance com os controles requeridos. Este domínio cuida da administra-
ção do processo de controle da organização de TI e da garantia de independência
provida por auditoria interna e externa ou obtida de fontes alternativas.
As dimensões são detalhadas em 34 processos (High-Level Control Objectives –

Objetivos de Controle de Alto Nível) e estes em 318 objetivos de controle que per-
mitem uma visão ampla sobre o que é requerido da área de TI em suas atividades para
atingir os objetivos do negócio e mitigar os riscos, fazendo uso dos recursos de TI,
pessoas, sistemas, tecnologia, instalações e dados.
O COBIT procura alinhar esses elementos à estratégia da organização e aos reque-
rimentos do ambiente.

CAPÍTULO 1 23
Os requerimentos de negócio em relação à informação quanto à qualidade, con-

fiabilidade e segurança consistem de:
Efetividade: informação precisa no prazo, forma e formato adequado.

Eficiência: provimento da informação de forma mais produtiva e econômica.
Conformidade (compliance): cumprimento das leis, contratos e regulamentações.
Confiabilidade: fornecimento de informações precisas e apropriadas aos
gestores para tomada de decisão, prestação de contas sobre finanças e com-
pliance.
Confidencialidade: proteção da informação a acessos não-autorizados.
Integridade: informação completa, acurada e validada de acordo com os valo-
res e expectativas do negócio.
Disponibilidade: informação disponível para o negócio quando requerida,
agora e no futuro, assim como a salvaguarda dos recursos necessários e capaci-
dades associadas.
Dessa forma, temos o cubo que o framework do COBIT se propõe a equacionar

por meio de seus objetivos de controle.
Para atingir os objetivos do negócio e atender aos requerimentos em termos das
informações, a área de TI deve planejar e prover a organização adequada dos recur-
sos de TI, adquirir e desenvolver as soluções de TI requeridas, entregar e dar suporte
a essas soluções e monitorar o ambiente.
Os objetivos de controle do COBIT procuram atestar como cada processo faz uso
dos recursos de TI para atender de forma primária ou secundária a cada requerimen-
to do negócio em termos de informação, cobrindo todos os seus aspectos.
Para cada um dos 34 processos o COBIT fornece, além dos objetivos de controle,
os fatores críticos de sucesso, os indicadores de resultado e os indicadores de perfor-
mance, permitindo uma abordagem ampla sobre o que se espera do processo, como
se medem os resultados esperados e como se mede a performance.
As métricas foram estruturadas com base no Balanced Business Scorecard, em
quatro perspectivas:
Financeira: Como os acionistas nos vêem?
Clientes: Como os clientes nos vêem?
Processos (internos): Como nós nos vemos?
Inovação e Aprendizado: Como podemos continuar a melhorar e gerar valor?
Os Key Goal Indicator para TI são os drivers de negócio, usualmente suportam as
perspectivas financeiras e clientes, são medidas que refletem se a meta foi atingida,
são medidas após o fato ocorrido. Já os Key Performance Indicators se referem às
perspectivas dos processos e da inovação, são medidas que refletem as tendências em
termos de atingir ou não a meta no futuro, são medidas antes do fato.

O COBIT também nos fornece um modelo para atestar a maturidade de cada pro-
cesso em uma escala de cinco estágios possíveis:
Não existente
Inicial, Ad hoc
Repetível, porém intuitivo
Processo definido
Processo otimizado
O COBIT fornece o detalhamento do que deve ser auditado em cada processo
com base em seus objetivos de controles. Todos os elementos, os detalhamentos e a
forma de implementação do COBIT estão organizados na família de produtos do
COBIT, disponível para download e uso não comercial no site www.isaca.org, ex-
ceto o audit guidelines.
O livro Implementation Tool Set fornece o roadmap para a implementação do
COBIT, incluindo exemplos de pesquisas e tabulações, sendo que, conforme sua po-
sição, o COBIT pode ter diferentes abordagens de uso:
Quando Você pode usar o Algumas abordagens que podem
você é… COBIT para... lhe ser úteis...
CIO Promover COBIT como Use COBIT para complementar a estrutura de
modelo de governança controles internos (por exemplo, COSO) com os
para a estrutura de TI. assuntos específicos de TI.
Use COBIT para auto-avaliar a organização da TI
em relação a um padrão aceito
internacionalmente.
Use o COBIT para estabelecer uma linguagem
comum entre Negócio e TI e para definir
claramente as responsabilidades.
Gerente Estruturar a TI, seus Use o COBIT para estabelecer SLAs e comunicar
de TI serviços e funções de com Negócio.
forma gerenciável, Use o COBIT como a base para medidas de
controlável, com desempenho dos processos inter-relacionados.
qualidade, segurança, Use o COBIT como a base para políticas e normas.
efetividade e foco na Use COBIT como o baseline para estabelecer o
contribuição para o nível apropriado de aceitação para os objetivos de
Negócio. controle e para certificações externas (por
exemplo, SysTrust e SAS 70).
Gerente de Estabelecer um modelo de Use o COBIT como código de boas práticas para
Negócio controles em comum com lidar com a TI nas funções de negócio.
TI para administrar e Use o COBIT para determinar os diferentes
monitorar a contribuição aspectos que precisam ser cobertos pelos Acordos
de TI para o negócio. de Níveis de Serviços (SLA) acordados com TI
(interna ou outsourced).

CAPÍTULO 1 25
Os modelos de diagnósticos do Implementation Tool Set podem ser utilizados em

processos de auto-avaliação. Existem modelos para diagnósticos dos controles, ris-
co, responsabilidades e SLAs.
O COBIT constitui uma importante ferramenta na estruturação e controle dos
processos de TI de forma a atender à demanda das diversas áreas da empresa, acionis-
tas, organismos regulatórios e entidades externas, por alinhamento, transparência e
equalização dos riscos de TI.
IT Governance Institute, COBIT (Control Objectives for Information and related Technology),
3a edição, 2000, www.ITgovernance.org and www.isaca.org
Board Brief on IT Governance
Executive Summary
Framework
Control Objectives
Management Guidelines
Implementation Tool Set
Peter Weill and Marianne Broadbent. Leveraging the New Infrastructure: How Market Leaders Capitalize
on Information Technology. Boston: Harvard Business School Press, 1998.
Robert S. Kaplan and David P. Norton. The Balanced Scorecard: Translating Strategy into Action. Boston:
Harvard Business School Press, 1996.
______. The Strategy-Focused Organization. Boston: Harvard Business School Press, 2001.
S. Mingay et al. The Five Pillars of IS Organisational Effectiveness. Stamford: Gartner Group, 1998.
Various Gartner research notes on IT Alignment and IT Value Delivery, 1996 – 2000.
J. Luftman, P. Lewis e S.Oldach. “Transforming the Enterprise: The Alignment of Business and
Information Technology Strategies”. IBM Systems Journal, v. 32, n. 1, pp. 198-21, 1993.
PricewaterhouseCoopers e The Institute of Internal Auditors Research Foundation, Corporate Go-
vernance and the Board–What Works Best, 2000.
Otimização da estrutura dos processos de TI – COBIT, ITIL

e demais conceitos, metodologias e ferramentas
O COBIT não determina como os processos devem ser estruturados, e sim os con-
troles que eles devem possuir para que TI cumpra seus objetivos em termos de go-
vernança, ou seja:

Então, como estruturar os processos de TI usando o framework do COBIT?

Será necessário avaliar os processos existentes em TI na empresa, fazer um gap
analysis em relação ao COBIT e modificar o que for necessário para atender aos obje-
tivos de controles, fazendo uso dos conceitos, das metodologias e das ferramentas
disponíveis no mercado.

Isso deve ser feito com base em uma metodologia para a modelagem de processos;
caso contrário, as representações e as formas de abordagens podem diferir muito en-
tre as várias áreas em TI, dificultando a integração delas.
Existem várias metodologias para modelagem de processos, ferramentas de
TQM (Total Quality Management), Seis Sigma, Design for Seis Sigma, BPR (Bu-
siness Process Redesign), BPM (Business Process Management), IDEF (integra-
ted DEFinition Methods) e outras metodologias proprietárias de diversas con-
sultorias de mercado.
Independentemente da metodologia adotada, os passos giram em torno de:
Levantamento da situação atual Análise e diagnóstico Desenho da situação
desejada Implementação Monitoramento
Levantamento da situação atual: é feito o mapeamento da situação atual com
base em diagramas, métricas e formulários em que são representadas as carac-
terísticas dos processos vigentes;
Análise e diagnóstico: com base em requerimentos do negócio, restrições do
processo, comparação com outros processos, requerimentos dos clientes e ou-
tras referências é realizada a análise de conformidade em relação ao referencial
escolhido;
Desenho da situação desejada: partindo-se da situação existente, é feito o dese-
nho do processo que contempla os GAPs em relação ao referencial escolhido,
respeitadas as restrições de recursos e os direcionamentos estratégicos;
Implementação: alteram-se políticas, normas, procedimentos, mecanismos,
acordos de níveis de serviços, indicadores e demais estruturas, conforme o
novo desenho do processo;
Monitoramento: são coletados e monitorados os indicadores conforme as fai-
xas de conformidade acordadas, atuando-se nos desvios e acompanhando as
tendências para manter o processo em um ciclo de melhoria contínua.
Considerando a figura clássica de representação macro de um processo (IDEF0),

o COBIT atua nos controles. As metodologias, pessoas, sistemas, infra-estrutura,
ferramentas de workflow e demais recursos são os mecanismos que irão transformar
os inputs e demandas da área de TI em soluções e serviços de TI com valor agregado
ao negócio.
Conforme a fase da modelagem dos processos de TI, a estrutura de controles
do COBIT auxilia na estruturação do levantamento, entendimento, gap analysis,
acompanhamento da implementação e monitoramento dos processos imple-
mentados.

CAPÍTULO 1 27
Quadro da relação do COBIT com a modelagem dos processos de TI
Fase da modelagem
dos processos Aplicação do framework do COBIT
Levantamento da O COBIT é utilizado na estruturação do levantamento, tomando por
situação atual base os domínios e os subdomínios.
Para esta fase o COBIT apresenta formulários para levantamento da
maturidade dos processos, riscos e outras características.
Análise e diagnóstico São utilizados os Objetivos de Controle e os Níveis de Maturidade do

COBIT para identificar os GAP´s dos processos atuais em relação ao
que se espera em termos de governança de TI (framework COBIT).
Desenho da situação Com base no GAP Analysis dos processos atuais em relação ao
desejada framework do COBIT, determina-se o que é necessário alterar e se
desenha os processos para chegar ao nível de maturidade desejado pela
empresa em cada subdomínio.
Implementação A implementação é realizada conforme a metodologia de modelagem

de processos adotada pela empresa.
O COBIT possui dois conjuntos de indicadores sugeridos que podem
ser utilizados nessa fase da modelagem dos processos:
– Indicadores de performance que avaliam se os processos estão
atendendo aos fatores críticos de sucesso.
– Indicadores de resultado que avaliam se os processos estão atendendo
aos requisitos de negócio em relação às informações (information
criteria) do framework COBIT.
Monitoramento O COBIT permite diferentes níveis de monitoramento dos processos:

– Indicadores de performance medem o dia-a-dia dos processos.
– Indicadores de resultado medem o atendimento dos information
criteria.
– Objetivos de controle evidenciam as boas práticas.
– Guia de auditoria.
Para alguns subdomínios do COBIT existem desenhos de processos consolidados

como sendo as melhores práticas do mercado, que podem ser implementados e cer-
tificados, tais como: ITIL, CMMi, PMBOK, ISO 17799, ISO 9000 e subdomínios
referentes ao gerenciamento da qualidade.
Porém para alguns subdomínios será necessário efetuar o ciclo de modelagem dos
processos existentes pela abordagem tradicional, buscando sempre atender aos ob-
jetivos de controle constantes no COBIT, pois serão as bases das auditorias futuras
nos processos de TI que seguirem esse framework.
“A disseminação do conhecimento permitiu à equipe de sistemas concentrar-se prioritaria-
mente nos processos relacionados à área de Tecnologia da Informação, o que a levou a adotar, a
partir do 2o semestre de 1999, o modelo Cobit nos trabalhos de revisão dos ambientes de infor-

mática. Tal metodologia, mundialmente reconhecida como a melhor prática de mercado, vem
sendo largamente utilizada com sucesso nos trabalhos do Desup nos últimos anos.” (Extraído
do site do Banco Central do Brasil em 2005.)
Cada vez mais a área de TI sustenta e alavanca os negócios das empresas e estrutura
os processos de TI, tendo por referência o framework do COBIT, o que é uma forma
de as empresas se prepararem para as exigências dos acionistas, do mercado e da le-
gislação em termos de boas práticas de governança em TI.
Trata-se de um programa de longo prazo que envolve vários projetos simultâ-
neos, devendo-se priorizar os planos conforme a estratégia da empresa, procurando
executar primeiramente os planos de maior retorno sobre o investimento em ter-
mos de satisfação para os clientes de TI ou redução de exposição dos riscos nos pro-
cessos de TI.
A implementação do programa de IT Governance não obedece a uma linearidade
rígida, conforme podemos ver na figura a seguir, pois os projetos que o compõe po-
dem ter seus escopos, prioridades, investimentos e outras características alteradas
ao longo do tempo, sendo necessária uma gestão da mudança ativa, que garanta a
continuidade do programa, a manutenção dos resultados e o envolvimento dos ges-
tores de TI por um longo período.
Os planos de ações podem requerer capacitação antes da execução, diante de um
plano o responsável deve se perguntar:
A equipe tem know-how e disponibilidade para a execução autônoma?
Com capacitação conceitual a equipe consegue executar de forma autônoma?
A equipe necessita de aporte de know-how externo? (conceito e/ou auxílio na
execução)
É necessário fazer de forma turn key com uma empresa externa?
Os líderes dos planos de ações devem ter ownership, ou seja, propriedade sobre os
planos, autoridade e responsabilidade, uma forma de amarrar essas coisas é por meio
de goals que contemplem os prazos e a aderência dos entregáveis dos planos, de for-
ma a atender o framework do Cobit dentro das expectativas da organização e com o
reconhecimento dos envolvidos no programa.
Essa é uma das formas de otimizar os processos de TI utilizando o framework do
Cobit com o objetivo de atingir:

Steven ten Have, Wouter ten Have, Frans Stevens e Marcel van der Elst. Modelos de Gestão: o que são e
quando devem ser usados. São Paulo: Prentice Hall, 2003.

CAPÍTULO 1 29
IT Governance Institute, COBIT (Control Objectives for Information and related Technology), 3a
Edição, 2000, www.ITgovernance.org e www.isaca.org
Board Brief on IT Governance
Executive Summary
Framework
Control Objectives
Management Guidelines
Implementation Tool Set
“Copyright 1996, 1998, 2000 Information Systems Audit and Control Foundation. Reprinted with
the permission of the Information Systems Audit and Control Foundation and IT Governance
Institute.”
http://www.sei.cmu.edu/publications/books/process/cmmi-process-int-prod-improve.html
http://www.pmi.org/info/default.asp
http://www.iso.org/iso/en/ISOOnline.frontpage
http://www.idef.com/IDEF0.html
http://www.isaca.org/
http://www.itsmf.com.br/
http://www.abnt.org.br/
http://www.bacen.gov.br
OTIMIZAÇÃO DO PROCESSO DE TOMADA DE DECISÃO EM TI

As decisões em TI, assim como em qualquer outra estrutura organizacional, são de
natureza estratégica, tática e operacional, e procuram responder os 5 Ws e 2 Hs
(why, what, when, where, who, how and how much): por que, o que, quando,
onde, quem, como e por quanto, e me permitam incluir, para quem, que é o nosso
cliente, como podemos ver, nem sempre lembrado em nossas decisões.
Assim vamos trabalhar os três tipos de decisões e seus grupos de questões prepon-
derantes (lembrando que as questões aparecem em maior ou menor grau em todas as
camadas de decisões, apenas são mais marcantes em uma que nas demais).
Grupo das questões para quem, por que, o que e quando.
Para o primeiro grupo de decisões, a governança em TI prega o alinhamento com

as áreas de negócio, desse modo, teremos a TI trabalhando de forma a gerar o valor
esperado para sustentar e alavancar o negócio.
Broadbent e Weill fizeram uma pesquisa com 256 empresas e publicaram um es-
tudo sobre as decisões em TI relacionadas a cinco aspectos específicos:
Estabelecimento dos princípios da TI.

Definições sobre estratégias de infra-estrutura.
Definições sobre a arquitetura de TI.
Necessidades de aplicativos de negócio.
Priorização dos investimentos.

Foi constatado que as decisões são tomadas segundo alguns arquétipos (estilos),
conforme quem toma as decisões em TI:
Monarquia do negócio os executivos seniores da empresa decidem sobre TI.

Monarquia de TI executivos de TI decidem.
Feudal os líderes das áreas de negócio (ou business unit) ou seus delegados de-
cidem sobre os aspectos de TI de suas unidades.
Federal as diversas áreas da empresa são representadas pelos seus executivos que
decidem como os recursos de TI serão divididos entre as unidades de negócio.
Duopólio executivos de TI e representantes das áreas de negócio decidem,
pode ser constituído de dois comitês: um executivo (horizontal) e um de TI
(vertical).
Anarquia cada dono de processo ou usuário final decide sobre sua TI.
A matriz dos tipos de decisões x arquétipos nos possibilita entender como são to-
madas as decisões estratégicas em cada empresa; não há uma matriz certa ou errada,
porém a mais encontrada pelos autores é:
Estratégias Necessidades Priorização
Princípios de infra- Arquitetura de de
de TI estrutura de TI aplicativos investimentos
Monarquia
Decide
Solicita
Solicita
Solicita
Solicita
Solicita
Decide
Decide
Decide
Decide
do negócio
Monarquia de TI X X
Feudal
Federal X X X X X
Duopólio X X X
Anarquia
É preciso, antes, entender a forma como a empresa decide essas questões es-
tratégicas de TI para implementar ou adaptar os objetivos de controle do Cobit,
que auxiliam no entendimento de como está a maturidade dos processos que su-
portam o planejamento e a organização de TI e qual a efetividade dos controles
vigentes.
A partir do gap analysis é possível atuar nos pontos certos e otimizar a forma como
as decisões estratégicas são solicitadas e tomadas em TI.
Grupo das questões quando, onde e quem.

CAPÍTULO 1 31
O segundo grupo de questões trata das decisões táticas em TI e se referem à aloca-

ção dos recursos de Hardware, Software e Peopleware (pessoas + capacidades + co-
nhecimento) para se atingir os objetivos estratégicos do negócio na parte em que TI
contribui, sustenta ou alavanca.
As demandas do negócio em termos de novas soluções de TI requerem o emprego
de HW, SW e PW em projetos, conforme as metodologias, os padrões, as ferramen-
tas e os controles adotados pela empresa.
As demandas do negócio em termos do ambiente operacional de TI, cada vez mais
complexo e sofisticado, também requerem o emprego de HW, SW e PW, desta vez
em processos operacionais de TI, conforme as metodologias, padrões, ferramentas e
controles adotados pela empresa.
Essa pressão da demanda sobre TI é respondida em termos dos recursos de HW,
SW e PW segundo um dos princípios da economia os recursos são escassos e limi-
tados.
Isso significa que os recursos de TI podem ser alocados para projetos, para proces-
sos, ou ambos, mas os deslocamentos desses recursos requerem tradeoffs, ou seja um
enfoque em projetos requer abrir mão de recursos em processos operacionais de TI,
e vice-versa.
COBIT
O COBIT (Control Objectives for Information and Related Technologies), patroci-
nado pelo IT Governance Institute, e agora em sua terceira edição, possui crescente
reconhecimento e é um modelo internacionalmente aceito como conjunto de me-
lhores práticas de controle das informações, TI e riscos relacionados.
Seu direcionamento permite implementar instrumentos de governança eficientes
sobre TI, o que é essencial a todas as empresas.
No Brasil, o COBIT vem sendo amplamente utilizado por empresas de diversos
setores e segmentos, além de ser base de avaliação de práticas de controle em TI para
Órgãos Reguladores como o Banco Central do Brasil e a Superintendência de Segu-
ros Privados (SUSEP).
®
Sobre o IT Governance Institute
O IT Governance Institute (www.itgi.org) foi fundado em 1998 com o objetivo de
promover avanços no pensamento internacional e desenvolver padrões para geren-
ciamento e controle da tecnologia da informação das empresas.
A governança eficaz de TI garante que a TI apóie os objetivos do negócio, otimi-
zando os investimentos em TI e gerenciando adequadamente os riscos e as oportuni-
dades relacionados a essa tecnologia.
O IT Governance Institute oferece simpósios, pesquisas e estudos de casos para
auxiliar os líderes e diretores das empresas em suas responsabilidades de gover-
nança de TI.

ITIL
O ITIL (Information Technology Infrastructure Library) é o modelo de referência
para gerenciamento de processos de TI mais aceito mundialmente.
A metodologia foi criada pela secretaria de comércio (Office of Government
Commerce, OGC) do governo inglês, a partir de pesquisas realizadas por consulto-
res, especialistas e doutores, com o objetivo de desenvolver as melhores práticas
para a gestão da área de TI nas empresas privadas e públicas.
Atualmente se tornou a norma BS-15000, sendo esta um anexo da ISO 9000/2000.
O foco desse modelo é descrever os processos necessários para gerenciar a in-
fra-estrutura de TI eficientemente e eficazmente de modo a garantir os níveis de ser-
viço acordados com os clientes internos e externos.
Entre os processos que fazem parte do modelo de referência, podemos citar: planeja-
mento de serviços, gerenciamento de incidentes, problemas, mudanças, configuração,
operações, segurança, capacidade, disponibilidade, custos, entrada em produção e testes.
As empresas que o adotaram estão preocupadas em gerar valor da TI para os
negócios da empresa e provar este valor de maneira adequada, através de proces-
sos corretos.
As normas ITIL estão documentadas em aproximadamente 40 livros, onde os
principais processos e as recomendações das melhores práticas de TI estão descritas.
O ITIL é composto por módulos. Os mais importantes são o “IT Service Support”
e o “IT Service Delivery”.
Características do ITIL
As principais características do ITIL são:
Modelo de referência para processos de TI não proprietário.

Adequado para todas as áreas de atividade.
Independente de tecnologia e fornecedor.
Um padrão de fato.
Baseado nas melhores práticas.
Um modelo de referência para a implementação de processos de TI.
Padronização de terminologias.
Interdependência de processos.
Diretivas básicas para implementação.
Diretivas básicas para funções e responsabilidades dentro de cada processo.
Checklist testado e aprovado.
O que fazer e o que não fazer.
Por que ITIL?

O ITIL conduz a uma forma de trabalho orientada a processos objetivando oferecer
um serviço de alta qualidade e garantia para os clientes da área de TI.

CAPÍTULO 1 33
As vantagens de trabalhar orientado a processos são listadas abaixo:

Faz com que as melhorias de qualidade possam ser medidas.
Torna os processos de gerenciamento dos serviços de TI mensuráveis.
Fornece uma forma consistente de trabalho.
Fornece uma terminologia padronizada.
Aperfeiçoa os processos de comunicação.
Aumenta a satisfação do cliente ajustando corretamente sua expectativa.
Auxilia na obtenção da certificação ISO 9000.
Metodologia ITIL para o gerenciamento de serviços de TI

Atualmente os processos de negócios estão mudando mais rapidamente do que a
própria infra-estrutura de TI.
A implantação de processos otimizados na área de TI é fator crítico de sucesso
para as grandes empresas. As novas tecnologias, bem como suas implantações
não ocorrem mais em anos e sim em meses, chegando a ser, em alguns casos, em
semanas.
A pressão por redução de custos e perguntas como: “Que serviços de TI serão ofereci-
dos?”, estão diretamente relacionadas ao valor que será gerado aos usuários e clientes.
Diante dessa necessidade foi criada a metodologia ITIL para gerenciar de maneira
eficiente a área de TI, bem como para prestar serviços de maneira otimizada e eficaz.
Os estudiosos chegaram à conclusão (independentemente do tamanho da empre-
sa) de que os custos de TI precisavam ser reduzidos e de que a qualidade do serviço
prestado por essas áreas tinha de ser melhorada, assim surgiu a metodologia ITIL.
A utilidade da metodologia ITIL

As normas ITIL descrevem o uso sistemático de processos para a gestão de serviços
de TI. Com isto a metodologia nos auxilia a ter:
Uma gestão mais eficiente da infra-estrutura e dos serviços prestados.
Maior controle nos processos e menores riscos envolvidos.
Eliminação de tarefas redundantes.
Definição clara e transparente de funções e responsabilidades.
Maior qualidade no serviço prestado.
Flexibilidade na gestão da mudança.
Possibilidade de medir a qualidade.
Redução de custos de TI.
Aumento da satisfação do cliente ou usuário.
Respostas e processos mais ágeis.
A comunicação se torna mais rápida e dirigida.
A organização de TI se torna mais clara e sistemática.
Os processos são otimizados, consistentes e interligados.

ITIL como o facto standard para o Service Management

Nos últimos anos a necessidade de uma metodologia voltada para processos de TI
cresceu, e com esse crescimento veio a necessidade da pesquisa para se ter um con-
junto de normas, assim, uma metodologia padrão para a área de TI era uma questão
de tempo.
A necessidade de se ter processos corretos, organizados e otimizados para prestar um
bom serviço de TI é fundamental. O foco da metodologia é prover as melhores práticas
para gerir planejamento, gerenciamento de incidentes e problemas, mudanças, configu-
rações, operações, capacidade, disponibilidade e custos de serviços de TI.
O sucesso dessa metodologia pode ser percebido nos tipos de empresa que vêm
implantando a mesma, como HP, Siemens e IBM.
As empresas que a adotaram, estão preocupadas em gerar valor da TI para os ne-
gócios da empresa e provar este valor de maneira adequada, por meio de processos
corretos, sendo uma organização proativa com tecnologia coerente e dentro das ne-
cessidades demandadas.
Os processos e módulos mais importantes estão descritos nos módulos “IT Servi-
ce Support” e “IT Service Delivery”. Cada um destes com seus respectivos submódu-
los como:
Service Support:
Service Desk
Incident Management
Problem Management
Configuration Management
Change Management
Release Management
Service Delivery:
Service Level Management
Finance Management
Capacity Management
Continuity Management
Availability Management
A seguir, alguns dos títulos de livros oficiais:

Software Asset Management
Service Support
Service Delivery
Planning to Implement Service Management
ICT Infrastructure Management
Application Management

CAPÍTULO 1 35
Security Management
The Business Perspective
Esses e outros livros sobre ITIL podem ser adquiridos no site:
www.tsoshop.co.uk/bookstore.asp?
Observação: O .co do endereço URL anterior está impresso corretamente! Ele está
localizado em um servidor web no Reino Unido (veja as letras .uk – de United King-
dom), Europa. Portanto, você deverá digitar mesmo o endereço mencionado utili-
zando .co.uk e não .com.uk. Lembre-se de que se tiver uma letrinha digitada errada
você não conseguirá carregar a página!
O leitor poderá fazer um “test drive” com o ITIL nos endereços a seguir:
Software Asset Management
Uma demonstração deste produto pode ser acessada no seguinte link:
http://www.tso.co.uk/samdemo
Service Support
http://www.tso.co.uk/ssdemo
Service Delivery
http://www.tso.co.uk/sddemo
Planning to Implement Service Management
http://www.tso.co.uk/pism
ICT Infrastructure Management
http://www.tso.co.uk/ict
Application Management
http://www.tso.co.uk/amdemo
Acesse também os links a seguir sobre ITIL:

http://www.ogc.gov.uk/
Office of Government Commerce
http://www.get-best-practice.co.uk/
Get-Best-Practice website
http://www.tso.co.uk/itil/
ITIL back catalogue
http://www.ogc.gov.uk/sdtoolkit/
Successful Delivery Toolkit

Sobre o itSMF
O IT Service Management Forum (itSMF) é a única organização internacional reco-
nhecida e independente dedicada a Gerenciamento de Serviços de TI. É uma organi-
zação sem fins lucrativos que pertence e é administrada por seus membros.
O itSMF é o maior influenciador e contribuidor mundial para as melhores práticas
e padrões da indústria de TI, trabalhando em parceria com um grande número de or-
ganizações, incluindo o Office of Government Commerce (OGC), o British Stan-
dards Institution (BSI), o Information Systems Examination Board (ISEB) e o Exami-
nation Institute of the Netherlands (EXIN).
Quais são os propósitos?

Desenvolver e promover as melhores práticas da indústria de TI para gerencia-
mento de serviços.
Incentivar o profissionalismo à comunidade de gerenciamento de serviços.
Fornecer um meio para auxiliar os membros a melhorar a performance dos ser-
viços de TI.
Proporcionar aos membros um fórum relevante no qual é possível comparti-
lhar informação e experiências com colegas de indústrias e segmentos dife-
rentes.
Estruturar grupos locais de interesse, viabilizando a distribuição da biblioteca
de ITIL e traduzindo material de apoio criado pelo itSMF UK (Reino Unido).
Quem são os membros do itSMF?

Os membros do itSMF originam-se de um vasto espectro. A maior parte deve repre-
sentar organizações “usuárias” que são responsáveis por entregar serviços de TI com
qualidade para seus “consumidores”, e também pelos representantes de fornecedo-
res líderes de produtos e serviços neste campo.
Membros usuários originam-se do setor público (federal, estadual e municipal) e
do setor privado (finanças, manufatura, varejo, telecomunicações, transportes
etc.). Empresas líderes de mercado podem ser encontradas entre os membros do
itSMF nos capítulos existentes.
Quais são os benefícios de fazer parte do itSMF?

Membros do itSMF beneficiam-se de:
Registro em seminários e conferências com taxas reduzidas.

Espaço de exibição com preços diferenciados.
Desconto em compras de livros.
Acesso a áreas restritas a membros no Web site.
Desconto nos anúncios em publicações e no Web site.

CAPÍTULO 1 37
Participação em grupos de discussão com colegas.

Oportunidade de contribuir no desenvolvimento das melhores práticas.
Acesso a catálogos de produtos e serviços.
Mais informações
Acesse o site www.itsmf.com.br ou envie um e-mail para: itsmf@itsmf.com.br
Grupos de Discussões Sobre ITIL no Brasil

No site do Yahoo Groups do Brasil encontramos diversos grupos de discussões rela-
cionados ao assunto ITIL. A seguir, uma breve lista dos e-mails de contatos para troca
de mensagens. Essa lista tende a crescer com o passar dos anos:
GE-ITIL-RS@yahoogrupos.com.br
ge-itil-sp@yahoogrupos.com.br
ge-itil-mg@yahoogrupos.com.br
Governanca_COBIT_ITIL@yahoogrupos.com.br
itgovernance@yahoogrupos.com.br
ITIL-Books@yahoogroups.com
itsm_br@yahoogroups.com
itil_brasil@yahoogrupos.com.br
Para participar de um dos grupos de discussão acima você deverá criar uma conta
se cadastrando no site www.yahoo.com.br
Links na Internet sobre ITIL

http://www.itsmf.com.br/
www.itil.co.uk
http://www.ogc.gov.uk/
http://www.get-best-practice.co.uk/
http://www.tso.co.uk/itil
http://www.ogc.gov.uk/sdtoolkit

Estudo de Caso3
FORD UNIFICA SERVIÇOS DE TECNOLOGIA DA INFORMAÇÃO

Montadora conta com a Siemens Business Services para integrar seus fornecedores
Unificar os diversos prestadores de serviços de tecnologia e gerenciar os recursos de infra-estrutura de
TI. Estes foram os desafios dados pela montadora Ford no Brasil para a Siemens Business Services, bra-
ço de tecnologia da informação do grupo. O trabalho se iniciou na fábrica de São Bernardo do Campo, na
Grande São Paulo, e foi estendido para a unidade fabril em Camaçari, na Bahia, e para as demais plantas
e escritórios no Brasil – ao todo quatro fábricas e 16 escritórios de vendas regionais. Com essa unifica-
ção, a Ford ganhou facilidade no gerenciamento e controle das atividades e aumento de produtividade.
Os funcionários da Siemens aplicaram alguns módulos da metodologia ITIL (IT Infrastructure
Library), trazendo para o Brasil os novos processos discutidos por um Fórum que reúne importantes
players voltados a encontrar novas soluções e excelência nos serviços de TI. “As empresas estão mu-
dando seus conceitos e querem experimentar novos processos para operação e governança em TI.
Funcionários da Siemens capacitados a implementar ITIL já colocam em prática alguns módulos aqui
no país, como acontece na Ford”, afirma Norberto Tomasini Junior, gerente de outsourcing da Sie-
mens. Ele explica que na Ford a orientação mudou de tempo de atendimento, performance de indicati-
vo para métricas de atendimento. “Agora o foco está em como atender ao usuário, qual a melhor forma
de satisfazê-lo e otimização do tempo de atendimento.”
Na Ford, a Siemens empregou dois módulos do ITIL (o incident management e problem manage-
ment), que foram combinados a uma outra metodologia já utilizada na montadora (Seis Sigma), com
objetivo de enfatizar a satisfação de seu cliente interno (help-desk que atende a todas as plantas da
Ford). “Os processos trazem um melhor gerenciamento da infra-estrutura de TI e uma administração
mais adequada no dia-a-dia”, explica Hudson Silvestre, supervisor de sistemas da Ford.
Iniciados em 2003, os novos processos na Ford foram decididos pela própria filial brasileira da
montadora. “Não seguimos diretrizes nesse caso. Decidimos optar pelo projeto de ITIL para melhorar-
mos os padrões de qualidade de TI, independentemente de qualquer decisão da matriz”, comenta
acrescentando alguns resultados obtidos: “Na medida em que o problem management encontra os
principais problemas recorrentes, eliminando-os ou solucionando-os, ganhamos em produtividade,
eficiência. Também ganhamos em gerenciamento, na administração do dia-a-dia, pois há disciplina
com enfoque em nosso cliente interno, transformando o cenário de TI num ambiente mais estável, com
recursos disponíveis em maior tempo possível”, afirma.
Ainda segundo Silvestre, combinando as duas metodologia (Seis Sigma e ITIL) o tempo de solução
de um problema é reduzido. “Efetivamente não é preciso ficar apurando sempre em cima dos mesmos
problemas e o ITIL contribui exatamente na sua identificação”, conclui.
De acordo com Norberto Tomasini, a Ford tem hoje formas de relatório com análises de reincidên-
cia, o que possibilita avaliar os locais e que tipo de problemas ocorrem, possibilitando entender exata-
mente o que acontece e precisa ser resolvido. Por esse motivo, a Siemens já se prepara para conquis-
tar a certificação BS15000 – um certificado de qualidade para os participantes do ITSMF (IT Service
Management Forum) que conseguem realizar a implementação dos módulos do ITIL dentro de seus
projetos, com prazos e metas estabelecidos pela entidade.
3 Colaboração: Siemens Brasil. www.siemens.com.br

CAPÍTULO 1 39
Profissionais da SBS: pioneiros em ITIL

O processo de capacitação dos funcionários da Siemens no Brasil teve início em maio de 2003, mês em
que consultores da Alemanha vieram ao país treinar a equipe brasileira. Nessa primeira etapa, foi defi-
nido o processo.
Depois de três meses, os consultores voltaram para avaliar a evolução do processo e implantar um
projeto piloto na Siemens VDO (fornecedora automotiva de eletrônica e mecatrônica de alta tecnolo-
gia). No final de novembro, com a finalização do projeto piloto, os funcionários capacitados a utilizar o
ITIL partiram para a implantação de todos os seis módulos em outros projetos.
Na última etapa, os consultores fizeram a auditoria dos projetos, e a Siemens Business Services no
Brasil chegou ao nível três, numa escala de cinco níveis.
Norberto Tomasini conta que o treinamento dos clientes da empresa já desperta atenção até do se-
tor público. “Os funcionários e empresas são todos treinados em palestras que mostram como enten-
der a linguagem. Além da Ford, temos outros projetos já implantados, e interesse de alguns governos
em conhecer o projeto.”
Sobre a Siemens Business Services

A Siemens Business Services (SBS) é fornecedora mundial e líder em serviços e soluções baseadas
em tecnologia da informação (TI). A divisão provê consultoria, gerenciamento, desenvolvimento e
integração de aplicativos e operações de soluções especiais e em plataformas e-Business. O portfo-
lio da SBS tem foco em System Integration, e-Business e Outsourcing. Neste último segmento, a
área já é uma das quatro maiores do Brasil. Com experiência em TI nos mais variados nichos de mer-
cado, a SBS proporciona aos seus clientes soluções personalizadas que resultam num poderoso di-
ferencial competitivo.
A SBS concentra a sua atuação nos seguintes mercados: serviços financeiros, indústria, saúde,
utilities e telecomunicações. No Brasil, entre seus clientes encontram-se empresas como Varig, Grupo
Abril, Ford, Basf, Votorantin, Vallourec & Mannesmann, Porto Seguro, TyssenKrupp, Gerdau e o próprio
grupo Siemens, entre outras. A base de clientes da SBS também inclui o setor público, com soluções
customizadas que atendem às mais diversas necessidades, inclusive e-goverment.
Sarbanes-Oxley4
Sobre a Sarbanes-Oxley
O ato de 2002 da Sarbanes-Oxley foi legalizado em 30 de julho de 2002, como res-
posta aos escândalos financeiros de grandes empresas respeitadas nos Estados Unidos
(WorldCom e Enron). Esses escândalos resultaram numa grande perda de confiança
pública nos balanços das corporações e em seus sistemas de informação.
4 Colaboração: Prof. Dr. Paulo Schmidt.

Algumas pesquisas e informações da época:
77% do público acredita que a ganância e a corrupção dos chefes executivos

causaram a queda financeira norte-americana (CNN/ USA Today, julho de
2002).
71% dos investidores afirmam que a fraude contábil é excessiva (Pesquisa a
Investidores na Main Street, julho de 2002).
82% dos investidores acreditam que são necessárias novas leis mais rígidas
(Harris Poll, julho de 2002 – Harris Poll é uma empresa de pesquisa).
54% dos gerentes dizem que não há apenas algumas maçãs podres entre as em-
presas (F.D. Morgan Walke Poll, agosto de 2002).
81% dos gerentes financeiros e analistas acham que os executivos colocam seus
próprios interesses na frente dos acionistas (Broadgate Consultants, março de
2002).
71% dos gerentes financeiros dizem que o pagamento do executivo é muito
alto e 0% dizem que é muito baixo ou justo (Pearl Meyer, junho de 2002).
70% das fraudes financeiras das corporações estudadas entre 1987 e 1999 en-
volviam chefes executivos (The Wall Street Journal, julho de 2002).
Abrangência da lei
Companhias abertas com sede nos Estados Unidos.
Companhias de investimento com sede nos Estados Unidos.
Fundos abertos ou fechados de investimentos com sede nos Estados Unidos.
Companhias que estão obrigadas a apresentar relatórios à SEC (Securities
Exchange Commission).
Companhias estrangeiras que tenham valores mobiliários (securities) negocia-
dos no mercado dos Estados Unidos:
Emissores de ADRs (American Depository Receipts)
Emissores de títulos de dívida (bonds)
O ato de 2002 da Sarbanes-Oxley estabelece novos padrões de responsabilida-
de contábil corporativa, bem como penalidades por danos da corporação. A le-
gislação contém 11 títulos, que vão desde responsabilidades adicionais para co-
mitês de auditoria a penalidades criminais mais rígidas para crimes de colarinho
branco, tais como fraudes de títulos. A SEC é incumbida de emitir normas que
implementam várias dessas cláusulas. As normas eventualmente emitidas pela
SEC podem ir além das exigências estatutárias.
Os principais tópicos são:
Responsabilização direta do CEO e do CFO pelas divulgações da compa-

nhia. No caso de divulgações erradas ou inexatas serão impostas penalida-

CAPÍTULO 1 41
des, tais como: (a) multa em até US$1 milhão e/ou prisão civil de até 10
anos nos casos em que o CEO ou o CFO saibam que o relatório não está de
acordo com as exigências da SEC e mesmo assim atestem sua veracidade,
(b) multa em até 5 milhões e/ou prisão civil de até 20 anos quando a viola-
ção for efetuada com dolo.
Participação efetiva do CEO e CFO na preparação dos relatórios da companhia.
Deve ser criado um sistema através do qual esses executivos realizem uma in-
vestigação independente e formal dos documentos contábeis que servirão para
eventual investigação criminal. Deverão, também, questionar e orientar os
responsáveis em todas as fases do processo.
A responsabilidade do CEO foi reforçada, pois este deve revisar os trabalhos
realizados pelo CFO bem como por outros departamentos da empresa. O siste-
ma de revisão de trabalhos pelo CEO deverá ser implementado pela própria
companhia, na melhor forma que lhe convier.
O CEO e o CFO deverão certificar os formulários 20-F declarando: (a) que o
relatório obedece integralmente aos requerimentos da SEC, não somente em
relação às demonstrações financeiras, mas em relação às demais informações da
companhia, (b) que as informações representam todos os aspectos financeiros e
operacionais da companhia.
A lei proíbe que as companhias, direta ou indiretamente, inclusive por intermédio

de subsidiárias, ofereçam, mantenham, ampliem e renovem empréstimos com
quaisquer conselheiros ou diretores.
Em relação aos empréstimos concedidos antes da promulgação da lei, ou seja, até
30 de julho de 2002, não estarão proibidos, todavia, não poderão sofrer quaisquer al-
terações relevantes nem mesmo ser prolongados ou renovados.
O comitê de auditoria criado pela lei é diverso do Conselho Fiscal das companhias
brasileiras. Deverá ser formado por membros do Conselho de Administração e ser
independente, não podendo ser afiliado da companhia ou de qualquer de suas subsi-
diárias.
A empresa de contabilidade deverá relatar ao comitê de auditoria todos os assun-
tos referentes às práticas e políticas contábeis essenciais, tratamentos alternativos de
informações financeiras e comunicações escritas relevantes entre a empresa de con-
tabilidade e a diretoria.
O comitê de auditoria deverá aprovar primeiramente todos os serviços de audito-
ria externa, bem como quaisquer outros serviços prestados por auditores indepen-
dentes não relacionados à atividade de auditoria. A aprovação de referidos serviços
deverá ser divulgada nos relatórios periódicos da companhia.
A lei proibiu a prestação de certos serviços de auditoria entre eles VALE
RESSALTAR:

a. Escrituração contábil ou quaisquer serviços referentes aos livros contábeis

ou demonstrações financeiras da empresa auditada.
b. Implementação de sistemas de informações financeiras.
c. Serviços de avaliação, laudos de avaliação de bens para aumento de capital.
d. Serviços de corretagem e banco de investimento, consultoria financeira,
serviços de advocacia e quaisquer outros serviços não relacionados com au-
ditoria.
O comitê será responsável pela escolha, remuneração e monitoramento das empresas
de auditoria/contabilidade. A SEC deverá adotar normas para que fique proibida a nego-
ciação de valores mobiliários de companhias que não obedeçam às regras de implementa-
ção e operação do comitê de auditoria nas bolsas de valores ou mercados de balcão.
Qualquer mudança substancial nas condições financeiras ou operacionais da com-
panhia deverá ser informada em tempo real, ou seja, de modo rápido e atualizado,
conforme solicitado pela SEC (em vigor).
A lei exige que a SEC adote regras a fim de exigir que a empresa informe se o Comitê
de Auditoria conta com, pelo menos, um membro experiente em assuntos financeiros,
bem como regras para que as companhias incluam em seus relatórios disposições refe-
rentes à divulgação de operações não contabilizadas e com empresas não consolidadas.
A lei determina que a SEC adote regras exigindo a divulgação de informações
sobre os controles financeiros internos de cada empresa. Cada relatório anual
deverá conter um relatório de controle interno e uma avaliação referente à efeti-
vidade da estrutura de controle interno e dos procedimentos para a divulgação
de informações financeiras, sendo que tal avaliação deverá ser confirmada e re-
portada pela empresa de auditoria externa que vier a preparar o relatório de au-
ditoria (sem prazo).
A lei exige, ainda, que a SEC proponha e adote regras exigindo que a empresa di-
vulgue se possui (ou, caso não possua, qual a razão) um código de ética para diretores
financeiros seniores, aplicável a seus principais diretores encarregados de assuntos
financeiros.
Caso a empresa divulgue alterações nas demonstrações financeiras por descum-
primento de exigências relativas ao modo de prestação das informações, como resul-
tado da violação de um dever de conduta pela empresa, o CEO e o CFO deverão de-
volver à empresa:
1. Qualquer participação nos lucros, bônus ou outra participação ou compen-

sação baseada em incentivos, paga pela empresa nos 12 meses subseqüentes
à primeira publicação ou arquivamento do documento contendo as demons-
trações financeiras errôneas;
2. Quaisquer lucros obtidos pelo CEO ou CFO com a negociação de valores
mobiliários da empresa durante os mesmos 12 meses.

CAPÍTULO 1 43
A lei permite à SEC eximir quaisquer pessoas dessas obrigações de devolução,

conforme julgue necessário e apropriado. A definição do significado de como deve
ser o resultado da violação de um dever de conduta pela empresa é um dos aspectos
que ainda está pendente de interpretação.
Os altos administradores e membros do conselho de administração de uma com-
panhia emissora não poderão comprar ou vender valores mobiliários representativos
do capital, de emissão da Companhia, adquiridos em virtude dos seus cargos.
A SEC deverá adotar regras estabelecendo padrões mínimos de conduta profissio-
nal para advogados que representem, de qualquer modo, Companhias Emissoras pe-
rante à SEC. Em decorrência da interpretação extensiva do que constitua represen-
tação perante à SEC, historicamente adotada, é possível que essas regras venham a
afetar advogados estrangeiros, incluindo integrantes de departamentos jurídicos, de
companhias emissoras. Regulamentação de responsabilidade profissional de advoga-
dos exigindo que estes comuniquem a existência de provas de atos ilícitos e descum-
primento de dever fiduciário devido à companhia emissora.
O direito de ação tendo por objeto questões relativas a fraude e manipulação de in-
formações envolvendo valores mobiliários prescreve em cinco anos após a ocorrência
do evento, ou dois anos após o descobrimento de sua ocorrência, o que for maior.
Empresas estrangeiras listadas (brasileiras são 37 companhias) na Bolsa de Nova
York terão até 15 de julho de 2006 para implantarem os controles internos exigidos
pela lei.
Para empresas estrangeiras que têm o ano fiscal coincidente com o ano calendário,
significa que os primeiros BP que terão explicações sobre os controles internos serão
publicados em 2007.
Estudo de Caso Sarbanes-Oxley
PRISMA, A EXCELÊNCIA NA GESTÃO DE CONTROLES INTERNOS5

Texto extraído da revista Petrobras de março/2005
Companhia implanta programa para integrar e certificar os seus controles internos

A busca pela excelência é uma característica da Petrobras em qualquer campo de suas atividades. Em
se tratando de ética e transparência na gestão, não poderia ser diferente. Agora, um novo capítulo nes-
sa evolução contínua começa a ser escrito com a criação de um programa para integrar e certificar os
controles internos da Companhia. O Prisma (Programa Integrado de Sistemas e Métodos de Avaliação
de Controles Internos) chega para reforçar o compromisso da Petrobras com a governança corporati-
va, levando a Companhia a um novo nível de excelência em gestão.
5 Colaboração: Petrobras – Petróleo Brasileiro S.A.: www.petrobras.com.br

“O Programa vai certificar e documentar os fluxos de informação, permitindo maior eficiência na

nossa gestão interna”, explica o diretor financeiro, José Sérgio Gabrielli. “O alto grau de conhecimento
dos nossos processos permite a identificação de eventuais lacunas bem como a possibilidade de oti-
mização.” A complexidade dos processos de uma empresa como a Petrobras exige a montagem de um
sistema igualmente complexo de acompanhamento. Ele envolve não somente as informações finan-
ceiras, mas também as relativas a outros processos e atividades, como reservas, gestão de riscos e
seguros. É preciso, ainda, que todos os processos sejam devidamente documentados, sem afetar,
contudo, o trabalho do dia-a-dia. “Esse é um grande desafio”, completa Gabrielli.
“Esse processo irá contribuir também, de forma significativa, com a segurança sobre os controles
internos e as informações contábeis da Petrobras e de suas Subsidiárias e Controladas, uma das me-
tas contínuas da Contabilidade”, complementa Marcos Menezes, Gerente Executivo do órgão.
Segurança e transparência
O conceito de controles internos é a chave para entender o alcance e a importância do Prisma. No caso
da Petrobras, o padrão adotado para embasar o programa é a estrutura de controles internos do COSO
(Comitê de Organizações Patrocinadoras da Comissão Treadway) composto pelos principais órgãos de
contabilidade e controle nos Estados Unidos. O COSO define os controles internos como um processo
que visa a dar segurança ao mercado e à empresa de que ela vai conseguir cumprir seus principais ob-
jetivos empresariais, como a confiabilidade das informações financeiras, a obediência às leis, além de
considerar a eficácia e eficiência das operações.
“O fortalecimento dos controles internos possibilitará uma maior interação de pessoas e proces-
sos em todos os níveis da companhia, desde o Conselho de Administração até as áreas operacionais,
passando por toda a administração da empresa”, afirma Gerson Luiz Gonçalves, Gerente-executivo da
Auditoria Interna da Petrobras e coordenador do Comitê de Gestão de Controles Internos. É exatamente
essa interação e integração que consolidam a chamada governança corporativa. “Eles são, portanto,
um meio para atingir um fim e não um fim em si mesmo”, explica. A certificação dos controles internos
melhora a imagem da empresa perante os investidores e favorece a captação de recursos com mais
facilidade e menores custos. “O Prisma vai nos ajudar a viabilizar os investimentos necessários para o
cumprimento das metas do plano estratégico na visão Petrobras 2015", conclui Gerson.
O Prisma foi concebido segundo um planejamento criterioso. A primeira etapa, concluída em janei-
ro de 2005, consistiu no mapeamento das empresas do Sistema Petrobras e dos seus processos rele-
vantes. Foi importante a implantação do SAP R/3 anteriormente ao início do Prisma. “Como o SAP é um
sistema integrado, grande parte dos processos mapeados para a Certificação dos Controles Internos
está contemplada em seu escopo e estamos trabalhando de forma também integrada com esta nova
realidade”, afirma Pedro Gauziski, Gerente de Certificação de Controles Internos, lotado na Auditoria
Interna e responsável pela operacionalização do Prisma.
A segunda etapa, com previsão de conclusão até abril/2005, engloba a documentação de todos os
processos internos, identificação de eventuais não-conformidades, bem como recomendação de so-
luções para os gestores. Até dezembro/2005, o Prisma deverá completar a terceira etapa: teste da efi-
cácia operacional dos controles. Toda documentação da estrutura de controles internos dos processos
das empresas selecionadas pelo programa em 2005 ficará armazenada em um portal institucional de
gestão integrada de riscos e controles, a serem avaliados e monitorados anualmente pela Auditoria
Interna e Gestores. Uma das conseqüências da conclusão dessas etapas será permitir que a Petrobras
atenda às exigências da Lei Sarbanes-Oxley (veja o quadro ao lado), permitindo a certificação anual da
estrutura de controles internos pelos Auditores Externos.

CAPÍTULO 1 45
“O Prisma objetiva integrar a governança à gestão de riscos e controles internos, fortalecendo, neste
processo, a cultura do Sistema Petrobras. Além de adotar as melhores práticas sugeridas, a força de tra-
balho poderá sempre contribuir elaborando sugestões para melhoria contínua”, completa Gauziski.
Conheça o Prisma
A abrangência do Prisma alcança todo o Sistema Petrobras, o que pode ser constatado pelas diversas
áreas e profissionais envolvidos com o Programa.
Componentes do Comitê de Gestão de Controles Internos:

Auditoria Interna, Abastecimento, Contabilidade, E&P, Finanças, Gás & Energia, Internacional, Recur-
sos Humanos, Relacionamento com Investidores, Tecnologia da Informação, Tributário e Petrobras
Distribuidora.
Profissionais atuando no Prisma:

Auditoria Interna, Abastecimento, Compartilhado, Contabilidade, E&P, Finanças, Gás & Energia, Inter-
nacional, Plafin, Recursos Humanos, Relacionamento com Investidores, SMS, Tecnologia da Informa-
ção, Tributário, Subsidiárias e Controladas.
A equipe do Prisma
n
115 empregados do Sistema Petrobras
n
10 administrativos
Lei Sarbanes-Oxley
O mercado de capitais sempre foi um dos pilares da economia global. Através dele, as grandes empre-
sas norte-americanas e de outros países financiam os seus investimentos, captando recursos por
meio da emissão de títulos e valores mobiliários. Esse pilar foi profundamente abalado por escândalos
corporativos recentes, como os casos Enron e WorldCom. Em função disso, as autoridades norte-
americanas agiram rapidamente para inibir a manipulação de dados contábeis e financeiros e assim
evitar maiores danos a uma de suas mais fundamentais instituições econômicas.
A Lei Sarbanes-Oxley, ou SOx, como também é conhecida, é um extenso conjunto de normas corporati-
vas idealizado pelos parlamentares norte-americanos Paul Sarbanes e Michael Oxley. Ela foi criada em
2002 para aumentar a segurança e a confiabilidade dos relatórios financeiros e privilegia o papel crítico do
controle interno. A lei exige controles e procedimentos que aumentam a responsabilidade dos executivos
das empresas listadas no mercado de capitais dos Estados Unidos, regulamentado pela SEC (Securities
and Exchange Commission), instituição equivalente à CVM (Comissão de Valores Mobiliários) no Brasil.
A Lei SOx atinge todas as empresas que negociam títulos e ações na Bolsa de Nova Iorque, como é o caso
da Petrobras, da PIFCo (Petrobras International Finance Company) e da PEPSA (Petrobras Energia Participa-
ciones S.A.), além de suas subsidiárias e controladas relevantes. Assim como a Petrobras, a maioria das em-
presas, norte-americanas ou não, atingidas pela Lei, tem adotado a estrutura COSO de controles internos.
Para a Petrobras, o cumprimento da Lei SOx será uma conseqüência natural de seu compromisso
contínuo com o aprimoramento de seus controles internos e de sua gestão. “A lei Sarbanes-Oxley bus-
ca tornar mais transparentes os fluxos de informação e a responsabilização pelas decisões, com o ob-
jetivo de permitir ao público externo ter confiança de que as informações geradas são fidedignas. Nes-
se sentido, a lei tem contribuições positivas para a governança corporativa e para uma gestão cada vez
mais responsável”, afirma o Presidente Gabrielli.

Implicações da Lei Sarbanes-Oxley na Tecnologia da Informação

Vem de longe a tradição norte-americana em ressaltar a figura do acionista minoritário
do mercado de capitais. Esta tradição foi fortemente abalada com os problemas contá-
beis e financeiros recentes verificados em empresas como Enron, WorldCom, Tyco e
Arthur Andersen, consideradas modelos de administração e da força do capitalismo.
O escopo da legislação federal “The U.S. Public Company Accounting Reform
and Investor Protection Act of 2002”, mais conhecida como Sarbanes-Oxley Act of
2002, se insere no âmbito da governança corporativa. Rígidos parâmetros legais fo-
ram impostos às companhias de capital aberto e às suas subsidiárias cujas ações são
negociadas em Bolsas (NYSE e Nasdaq), o que inclui algumas corporações estrangei-
ras que negociam ADRsi naquele país, alçados à força de lei.
A partir da promulgação da Sarbanes-Oxley, o que era recomendável passa a ser
obrigação legal: a boa governança e a ética nos negócios de companhias com presença
no mercado mobiliário.
Em suas 1.107 Seções, a Sarbanes-Oxley imputa responsabilidades jamais vistas
perante os diretores de corporações, que vão desde o pagamento de multas (que po-
dem chegar a U$ 5 milhões) ao cumprimento de longas penas de reclusão, sanções
estendidas aos auditores que atestarem balanços com números fraudulentos.
Ao regular a atividade de contabilidade e auditoria das empresas de capital aberto,
a Sarbanes-Oxley reflete diretamente seus dispositivos nos sistemas de tecnologia da
informação. Impossível separar-se processos de negócios e tecnologia no panorama
corporativo atual.
A Seção 404 da lei é o principal foco de atenção das empresas neste particular, por
trazer os mandamentos sobre os controles de processos internos e sistemas contábe-
is. Ela determina uma avaliação anual dos controles e processos internos para a reali-
zação de relatórios financeiros, com a obrigação de emissão de relatório, a ser enca-
minhado à SEC para atestar esses parâmetros. Esse relatório deve conter:
Atestado de responsabilidade dos administradores da empresa e manutenção da

estrutura dos controles internos e demais procedimentos.
Avaliação e relatório de cumprimento de metas, ao final de cada ano fiscal, da
eficácia dos procedimentos internos adotados para emissão de relatórios finan-
ceiros.
Declaração que o auditor independente da companhia atestou a avaliação dos
procedimentos elaborada pela administração.
Os tais “processos” e “controles” internos se aplicam em sentido amplo, vale di-

zer, todo e qualquer procedimento administrativo que resulte em números passíveis
de auditoria (a lei descreve quais são os procedimentos não auditáveis).
Assim temos, por força da Sarbanes-Oxley, a obrigatoriedade da observância de
práticas de segurança de redes e critérios rígidos para uso de aplicações terceirizadas

CAPÍTULO 1 47
por companhias que se encontram ao alcance da presente lei. Invasões em sistemas,

ataques, vírus, roubo de dados, fraudes de senhas e demais ameaças à segurança das
informações da companhia podem, se não houver prova suficiente de adoção de me-
didas preventivas coordenadas com os parâmetros da Seção 404, implicar responsa-
bilidade direta dos administradores, surgindo daí possibilidades concretas de sanções
civis e penais.
Verificamos dois pontos de preocupação imediata no que toca o uso da tecnologia
da informação inserido no âmbito da Sarbanes-Oxley:
Segurança de sistemas de informação – a adequação do conteúdo da Sarba-
nes-Oxley deve se dar entre toda a cadeia de comunicação da empresa, principal-
mente nos recursos concernentes a informações financeiras. Sistemas de ERP,
aplicativos contábeis, sistemas de CRM, Supply Chain Management, em conjunto
com as demais aplicações de comunicação, banco de dados e armazenamento de in-
formações precisam estar em sintonia com as regras adotadas na legislação. Em
contínuo, a atenção do administrador deve se estender à utilização de todo e qual-
quer recurso tecnológico da empresa por parte dos funcionários, e as políticas de
segurança da informação adotadas devem ser adaptadas ao teor da Sarbanes-
Oxley. Especial atenção também deve ser conferida ao outsourcing. Nos Estados
Unidos, a chamada cybersecurity liability começa a ter evidência entre os executi-
vos financeiros.
Controle de registros – um repositório de registros de procedimentos adequado é
fundamental para o sono tranqüilo dos diretores e presidentes do conselho de adminis-
tração das corporações. Estes registros devem ser tangíveis (papel) ou intangíveis (ar-
quivos e demais mídias), e a redundância em sistemas de back-up é altamente reco-
mendada. No bojo da lei encontram-se disposições que penalizam severamente a falsi-
ficação, destruição e perda de documentos e registros, bem como prevêem a observa-
ção de prazos para seu armazenamento após o fechamento de cada exercício fiscal.
A adoção de diretrizes para a segurança da informação que alcancem toda e qual-
quer contratação de tecnologia é uma atitude salutar e extremamente recomendável
no momento pós-promulgação da lei em foco.
Verificamos que a mera configuração de tentativa de fraudar relatórios financei-
ros é passível de multas altíssimas e penas restritivas de liberdade sob a ótica da Sarba-
nes-Oxley, e mais do que nunca, a atitude preventiva é uma das melhores práticas no
sentido de obstar suas conseqüências.
A revisão de processos, reestruturação de conselhos e adoção de políticas que dis-
seminem o conceito de governança corporativa buscado pelo legislador no caso de
companhias sob as asas da lei batizada de Sarbanes-Oxley são medidas obrigatórias e
urgentes. Os fornecedores de soluções de tecnologia da informação ganham novas
possibilidades para desenvolvimento de ferramentas que auxiliem os administrado-
res neste particular, uma vez que todos os processos empresariais internos, hoje, de-
pendem intrinsecamente de recursos tecnológicos.

Segurança da informação
Uma companhia alcança o seu valor de acordo com a mensuração de seus ativos. Três
elementos são vitais para as organizações nos dias de hoje: ativo, capital intelectual e
ativos intangíveis.
Delineando a conceituação de “ativo”, temos:
“...ativo é a totalidade dos recursos econômicos, materiais ou não, de proprieda-
de da empresa ou que esteja no gozo de seu uso e posse, sendo utilizados na conse-
cução dos fins operacionais da entidade e que gerem uma expectativa positiva em
seu fluxo de caixa futuro.”
Dentro dessa totalidade de recursos, é de conhecimento geral que o capital inte-

lectual toma a dianteira na valorização dos ativos empresariais. Assim, o capital inte-
lectual é definido como:
“...conhecimento que existe em uma organização que pode ser usada para criar
uma vantagem de diferencial no mercado.”
O conhecimento acumulado nos limites da empresa torna-se um ativo, porém,

diferenciado dos ativos de idos tempos, onde a materialidade ditava a riqueza da
companhia com seu número de edifícios, maquinário, estoques e instalações físicas.
Tais ativos apresentam o elemento intangibilidade, ou seja, são imateriais, voláteis,
incorpóreos, formados pela geração, armazenamento e organização do capital inte-
lectual desenvolvido na empresa:
“O mesmo que Ativo Imaterial; encerra valores que não encontram um corres-
pondente corpóreo, como: Fundo de Comércio ou Aviamento, Patentes de in-
venção etc. Pode ser chamado, também, Ativo Incorpóreo.”
Ao não se configurar um bem corpóreo, temos que o ativo imaterial mais valioso
pode ser melhor traduzido em uma simples palavra: informação. Alçada ao Olimpo
nas organizações, que neste início do século XXI já incorporaram plenamente sua
importância, a informação recebe proteção cada vez mais apurada, uma vez que é
transportada em sistemas tecnológicos, com o amadurecimento da Tecnologia da
Informação. Este amadurecimento propiciou a fruição dessa informação de maneira
segura, com o aprofundamento de técnicas e a formação de uma verdadeira ciência
computacional voltada para o uso de recursos informáticos.
Evento divisor: 11 de setembro de 2001

Sem embargos, podemos afirmar que o evento divisor no desenvolvimento das tec-
nologias de segurança da informação foi o ataque ao complexo de edifícios World
Trade Center. Ao promover a completa destruição de grandes edifícios que simboli-

CAPÍTULO 1 49
zavam a pujança econômica dos Estados Unidos, os agressores conseguiram seu ob-
jetivo: atingiram o capitalismo, pulverizando por completo um grande número de
empresas que tinham na informação seu principal ativo. Aniquilando vidas e empre-
sas, os responsáveis promoveram uma inquestionável modificação nos ditames da
organização do trabalho, em sentido amplo.
O resultado dos ataques foi devastador, porém diferenciado entre as vítimas, em
particular pessoas jurídicas, no que tange à continuidade de negócios. Enquanto uma
empresa do setor financeiro possuía seu sistema de back-up em um edifício no Estado
de New Jersey, a poucos quilômetros do local da tragédia, uma outra do mesmo seg-
mento armazenava toda sua informação no outro edifício atacado, imaginavam, os
gestores de segurança, que nada aconteceria aos dois prédios simultaneamente. O
que parecia impossível aconteceu, e juntamente com o conjunto de seus ativos ima-
teriais a empresa sucumbiu. Após esse trágico episódio, a palavra segurança entrou
para o rol das mais ouvidas, discutidas e almejadas no ambiente corporativo ao redor
do globo.
Muitos pontos relativos ao gerenciamento de dados corporativos foram levanta-
dos e amadurecidos após os ataques terroristas ao WTC. Normas como a ISO 17799
e Cobit receberam prioridade, políticas de segurança começaram a se disseminar,
gerenciamento de continuidade de negócio recebeu foco por parte dos gestores, ou
seja, os liames da palavra “segurança” chegaram aos seus estertores no que se refere
ao ambiente empresarial.
Vimos, portanto, uma nova mentalidade corporativa, iniciada nos Estados Uni-
dos, que se espalha por todo o mundo, e que trouxe à luz a necessidade de maior apri-
moramento de táticas preventivas para a continuidade das operações de negócios,
cada vez mais dependentes de sistemas de informação.
Escândalos contábeis e Sarbanes-Oxley Act

Em seguida aos acontecimentos que culminaram na perda de vidas inocentes e com-
panhias sólidas, verificamos, também em território norte-americano, os escândalos
contábeis envolvendo algumas empresas consideradas modelos do capitalismo:
WorldCom, Tyco, Enron, Arthur Andersen e outras de menor porte estiveram en-
volvidas em manipulação de resultados financeiros, gastos astronômicos, desvio de
informações e fraudes contábeis com auxílio de auditores independentes.
Após apuradas as infrações em série perpetradas pelos administradores destes íco-
nes da pujança econômica americana, iniciaram-se movimentações no sentido de re-
gular mais fortemente o mercado mobiliário, uma vez que a figura do investidor
sempre recebeu atenção por parte da Security Exchange Commission, órgão res-
ponsável pela saúde do sistema de ações. Essas movimentações culminaram em uma
legislação que revolucionou o setor mobiliário mundial, “The U.S. Public Company
Accounting Reform and Investor Protection Act of 2002" que ficou conhecida como
Sarbanes-Oxley.

A Sarbanes-Oxley, em suas 1.107 seções, é o ápice do regramento em torno da

boa governança corporativa, imputando obrigações e penas pesadas em caso de desa-
cordo de registros e relatórios financeiros.
A lei implica imediatos reflexos na segurança da informação corporativa, uma vez
que sistemas geram, armazenam e transportam os dados financeiros da companhia.
Os registros agora necessitam ser analisados por um auditor, assim como todo o ca-
minho da informação, seu acesso, resguardo, controle e armazenamento, por prazos
que podem superar cinco anos após o referido exercício.
Em nossa vida prática nos Estados Unidos, temos visto um excessivo cuidado com a
chamada cybersecurity liability, vale dizer, a responsabilidade sobre o funcionamento,
disponibilidade e segurança dos sistemas informáticos da empresa. Neste esteio, tal
responsabilidade é estendida diretamente ao CEO e CFO da organização, em conjunto
com o CSO, em caso de falta de cuidados preventivos no que se refere ao tráfego de da-
dos relevantes, em face da Sarbanes-Oxley. Assim, recursos são dispensados na busca
de padrões internos confiáveis, fomento de cultura de segurança, sistemas de rastrea-
mento de dados e comunicação corporativa entre unidades operacionais.
Concluindo, temos presente um novo paradigma em face da atividade de proteger
ativos intangíveis referentes à tecnologia da informação, paradigma trazido à luz por
acontecimentos recentes, que inauguraram uma nova era nos parâmetros da segu-
rança da informação. O que era recomendável passa a ser obrigatório.
Estudo de Caso6
SIEMENS INOVA EM SISTEMA PARA SEGURANÇA DE DADOS

A empresa é uma das pioneiras no mercado a aderir à Lei Sarbanes-Oxley
A Siemens, uma das empresas líderes no setor de eletroeletrônicos, está se adequando à Sarbanes-Oxley,
que prevê controle de processos, acessos e máquinas com o objetivo de orientar orçamentos para reduzir o
risco dos negócios e evitar fraudes. A Sarbanes-Oxley (SOx) é uma lei criada em 2002, por senadores nor-
te-americanos, devido aos grandes escândalos de fraudes financeiras nos Estados Unidos que abalaram o
mercado de capitais. Com 1107 artigos, a SOx obriga as companhias de capitais abertos a reestruturarem
processos, para aumentar a transparência em contratos de vendas, de compras, de gestão de identidade e
gestão da informação. A Siemens saiu na frente e foi a primeira empresa no Brasil a adquirir o ARIS SOX Ma-
nager, criado pela IDS Scheer, especialmente para a adaptação à Lei.
Este processo de adequação foi iniciado pela matriz, na Alemanha, e logo em seguida no Brasil. No
país a empresa está implantando e alterando soluções para concluir todas as mudanças até abril deste
ano. Segundo Jairo Martins, diretor de Tecnologia da Informação da Siemens para o Mercosur, a empre-
sa está revendo os sistemas de compras, vendas e de perfis, por meio da aplicação do sistema de Gover-
nança de TI. “Atualização da plataforma de notebooks e desktops, gestão de identidades, comitês de au-
ditorias e relatórios periódicos, são algumas das ferramentas que estamos utilizando”, afirma Martins.
6 Colaboração: Siemens do Brasil. www.siemens.com.br

CAPÍTULO 1 51
O software ARIS SOX Manager é pioneiro no mercado e desenvolvido exclusivamente para a adequação
à Lei. “Muitas empresas estão utilizando a Sarbanes-Oxley para colocar a ‘casa em ordem’”, comenta Mar-
tins. A Siemens está aproveitando e revendo ferramentas de controle na área de TI (1). “Estamos mudando
programas de senhas, oferecendo palestras para conscientizar os colaboradores, definindo itens e avalia-
ções mais rigorosas para relatórios, e construindo comitês de auditorias”, conclui o executivo.
A Governança Corporativa juntamente com a Governança de TI são modelos de gestão que visam moni-
torar e implementar controles internos, garantindo a integridade das informações por meio de sistemas
integrados e seguros. O prazo para a conclusão da adequação é novembro de 2005. A Siemens pretende
atualizar seus sistemas de controles em 126 filiais, espalhadas por todo o mundo, até abril desse ano (1).
Sobre a Siemens no Brasil

Há quase 100 anos, a Siemens participa da vida econômica brasileira, fornecendo infra-estrutura tec-
nológica para telecomunicações, indústria de base, energia elétrica, transporte metro-ferroviário, ele-
tro-medicina e iluminação. O grupo no Brasil conta hoje com mais de 8 mil colaboradores e é composto
por 12 fábricas. A subsidiária brasileira está entre os 10 mais importantes mercados para o grupo Sie-
mens. Em outubro de 2002, a empresa passou por uma reestruturação, sendo colocada em prática
uma organização regional, a Siemens Mercosur. A nova empresa é formada, além do Brasil, pelas Sie-
mens Argentina e Chile, que atendem também aos mercados da Bolívia, Paraguai e Uruguai. Toda a in-
trodução dos novos produtos é feita a partir do Brasil. Hoje, a empresa conta com nove regionais no
país: Porto Alegre, Belo Horizonte, Brasília, Rio de Janeiro, Salvador, Recife, São Paulo, Curitiba e Cam-
pinas. Os dados divulgados neste press release referem-se ao balanço da Siemens no Brasil.
Estudo de caso publicado com a autorização da Siemens do Brasil.
Para mais informações sobre a Siemens Brasil acesse o web site www.siemens.com.br
INTRODUÇÃO AO GERENCIAMENTO DE PROJETOS

Conceito de Projeto
Enxergo a vida como se ela fosse um conjunto de pequenos projetos diários que so-
mados nos levam na direção de um grande projeto.
Cito a vida em seu sentido mais amplo: pessoal e profissional, ou seja, o ser huma-
no e o ser homem de negócios. Gerenciar as duas faces da vida pelo prisma dos proje-
tos faz a gente enfrentar os desafios pessoais e profissionais com mais segurança.
Podemos utilizar o conceito de projeto em todas as situações cotidianas, por
exemplo, escrever um livro, organizar um casamento, uma festa de 15 anos, progra-
mar uma viagem de 15 dias para o Egito ou fazer compras em um supermercado. Se
essas atividades não são tratadas como pequenos projetos, ou seja, planejadas com
antecedência e bem gerenciadas através de uma metodologia pessoal ou científica,
alguma coisa tende a dar errado.
Mas, afinal de contas, qual é o conceito de projeto?
O PMBOK define projeto como sendo “um empreendimento temporário com o
objetivo de criar um produto ou serviço único”.

Vamos analisar um conceito de projeto citado por Vargas. “Projeto é um empre-

endimento ou evento não-repetitivo, caracterizado por uma seqüência clara e lógica
de eventos, com início, meio e fim, que se destina a atingir um objetivo claro e defi-
nido, sendo conduzido por pessoas dentro de parâmetros predefinidos de tempo,
custo, recursos envolvidos e qualidade”.
Na seqüência, ele complementa explicando cada parte do conceito:
É um empreendimento não-repetitivo: é um evento que não faz parte da rotina da

empresa. É algo novo para as pessoas que o realizarão.
Caracterizado por uma seqüência clara e lógica de eventos: é composto de atividades
encadeadas logicamente de modo a permitir que, durante a execução, o acom-
panhamento e controle sejam precisos.
Com início, meio e fim: todo projeto respeita um ciclo de vida. Um projeto, po-
rém, que não tenha término não é um projeto, é rotina, e, além disso, torna-se
mais um problema para a empresa resolver.
Que se destina a atingir um objetivo claro e definido: todo projeto tem metas e resul-
tados bem estabelecidos a serem atingidos em sua finalização.
Sendo conduzido por pessoas: o cerne fundamental de qualquer projeto é o ho-
mem. Sem ele, o projeto não existe, mesmo que se disponha de equipamentos
modernos de controle e gestão. Projetos utilizam recursos, que podem ser pes-
soas qualificadas para determinados trabalhos ou software e hardware.
Dentro de parâmetros predefinidos de tempo, custo, recursos envolvidos e qualidade:
todo projeto necessita do estabelecimento de valores para prazos, custos, pes-
soal, material e equipamentos envolvidos, bem como a qualidade desejada para
o projeto. É impossível estabelecer, previamente, com total precisão, esses pa-
râmetros. Todos eles serão claramente identificados e quantificados no decor-
rer do plano do projeto. Entretanto, os parâmetros iniciais vão atuar como re-
ferências para o projeto e sua avaliação.
Outros autores como Cleland e Meredith também conceituaram projeto.

Para Cleland, “projeto é uma combinação de recursos da empresa, os quais traba-
lham em conjunto para criar ou desenvolver um produto que não havia sido con-
cebido antes, com objetivo de melhorar a performance no planejamento e na reali-
zação de estratégias organizacionais”. Para Meredith, “projeto é uma atividade
única e exclusiva com um conjunto de resultados desejáveis ao seu término”.
Além disso, ele ressalta que “um projeto é complexo o suficiente para necessitar
de uma capacidade de coordenação específica e um controle de prazos, relacio-
namentos, custos e performance”.
Cleland e Meredith citam a palavra performance em seus conceitos, o que merece
um breve comentário. Não vou me aprofundar no campo semântico da palavra per-
formance, mas nesse caso podemos entendê-la de duas maneiras: aumento da produti-

CAPÍTULO 1 53
vidade e utilização de recursos de forma efetiva, atingindo todos os níveis da organi-

zação, dois aspectos que justificam a fomentação e a execução de projetos nas organi-
zações.
Cabe mais uma observação sobre projetos. Projetos envolvem incertezas porque
o objetivo é obter um produto único, nunca realizado anteriormente. Essas incerte-
zas tornam-se ainda mais críticas em projetos de tecnologia da informação. Adminis-
trar as incertezas em prol do projeto é um dos grandes desafios do gerenciamento de
projetos.
Projetos versus operações rotineiras

Antes de abordarmos este assunto, vamos imaginar o seguinte cenário que vi em uma
charge de “Thaves”: dois trabalhadores de uma fábrica que tinham como função so-
mente o apertar de porcas em parafusos. Estes, depois de apertados, seguiam por
uma esteira rolante para uma outra ala da fábrica, dando seqüência à linha de produ-
ção. Um dos trabalhadores comentou com o seu companheiro de esteira que se apo-
sentaria no dia seguinte e que caminharia até o final da linha de produção para desco-
brir qual era o produto final do apertar de porcas nos parafusos, processo do qual
participara nos últimos 30 anos. Esse mesmo cenário me lembra também o tema do
filme de Charles Chaplin, Tempos Modernos, em que percebemos claramente o exem-
plo de operação rotineira.
As operações rotineiras são os serviços repetitivos dentro de uma organização.
Por exemplo, a entrada de dados de uma folha de pagamento utilizando uma planilha
eletrônica. Pelo fato de esse procedimento ocorrer todo o mês e ser feito pelas mes-
mas pessoas e da mesma forma, ele é caracterizado como sendo uma rotina operacio-
nal (ou operação rotineira), na qual as tarefas não são inovadas e as pessoas não têm
muita oportunidade de aprender coisas novas, exceto quando ocorrem mudanças
nas legislações trabalhistas.
Mesmo assim, essas pessoas ainda se sentirão limitadas pelos recursos da planilha
eletrônica, que não foi concebida especificamente para processar os dados de uma
folha de pagamento. A característica desse tipo de atividade é a continuidade, en-
quanto os projetos são temporários, ou seja, têm data e expiração; e produzem servi-
ços ou produtos únicos, diferentes de todos os produtos e serviços semelhantes,
além de promoverem um ambiente perfeito para tarefas inovadoras e o crescimento
profissional dos recursos humanos.
Tomando como exemplo o mesmo caso da folha de pagamento, poderíamos fo-
mentar um projeto de melhoria de processos na organização, cujos procedimentos
seriam implementados e melhorados. Esse projeto poderia ter como um dos produ-
tos principais a adoção de um novo sistema para o processamento da folha de paga-
mento, que aboliria a utilização de planilhas eletrônicas.

A história evolutiva do gerenciamento de projetos

Antes de entrarmos no assunto de gerenciamento de projetos, vamos conhecer um
pouco de sua história evolutiva de acordo com a ótica norte-americana, mais aceita nos
dias de hoje. Dessa forma, será possível vislumbrar suas perspectivas de evolução.
Como já vimos, o gerenciamento de projetos não é uma novidade. As grandes obras e
feitos da antiguidade, tais como as pirâmides do Egito, a muralha da China, os templos da
Grécia, dentre outros monumentos e grandes construções históricas, certamente neces-
sitaram das habilidades de coordenação e planejamento de um gerente de projetos.
Entremos agora no túnel do tempo. Vamos para meados do século XX. De acordo
com a maioria dos especialistas no assunto, a maior parte da gestão de projetos mo-
dernos surgiu durante a Segunda Guerra Mundial, com o Projeto Manhattan, tendo
sido aprimorada em outros projetos de âmbito militar, tais como o Projeto Polaris e o
Projeto Homem à Lua.
Vejamos então um pouco dessa evolução.
O Projeto Manhattan
O Projeto Manhattan foi executado pelos militares dos Estados Unidos com o objeti-
vo de construir a bomba atômica. O orçamento deste projeto para aquela época era
de US$2 bilhões e foi iniciado na primavera de 1942. Teve em seu comando, em vez
de cientistas e engenheiros experientes, um militar, com vasta experiência em admi-
nistração, que já havia participado do gerenciamento do projeto de construção do
Pentágono – o General Leslie Groves.
O Projeto Polaris
O objetivo deste projeto era melhorar o sistema de defesa norte-americano. Ele foi
realizado pela Marinha dos Estados Unidos durante o apogeu da Guerra Fria e utili-
zou muitas das técnicas adotadas no Projeto Manhattan, além de ter desenvolvido no-
vas, tais como: diferenciação da equipe, cooperação, disciplina e foco no resultado e
inovação gerencial com adoção de ferramentas como PERT, Planos de Gestão e Téc-
nicos, reuniões executivas semanais e centro de gerência (predecessor do conceito
do PMI, PMO – Project Management Office).
O Projeto Homem à Lua

Os conceitos dos projetos Manhattan e Polaris foram evoluindo e sendo aprimorados
pela NASA durante o Programa Espacial Norte-americano.
Esse mega projeto envolveu milhares de fornecedores, os quais se viam obrigados
pela NASA, através de contratos, a adotarem técnicas de gestão especiais, que, com-
provadas através de projetos antecessores, proporcionavam melhores resultados.
Foi necessário que a própria NASA os capacitassem na utilização dessas técnicas
mais eficientes. Isso gerou uma grande disseminação desses conhecimentos e práti-
cas no mercado, não ficando limitado à área militar.

CAPÍTULO 1 55
Essas técnicas se espalharam pelos quatro cantos da Terra. A NASA possui em seu
Web site um vasto repositório, de acesso livre via Internet, descrevendo as diversas
técnicas de gestão e documentos de projeto que servem de exemplos na adoção des-
sas práticas.
Falando em Internet, vou abrir um parêntese e lembrar um pouco a história do ge-
renciamento de projetos para o tema central deste livro, a tecnologia da informação.
Muitos projetos de tecnologia da informação foram importantes para a evolução
dos recursos que temos nos dias atuais, porém é preciso reconhecer que o advento da
Internet foi um marco na história da computação mundial.
Por isso, abordarei brevemente como surgiram os Projetos da Internet Mundial, o
Projeto World Wide Web e o Projeto da Internet no Brasil.
O Projeto Internet Mundial

A Internet nasceu em 1969, nos Estados Unidos. Interligava originalmente laborató-
rios de pesquisa e se chamava ARPAnet (ARPA: Advanced Research Projects Agency).
Era uma rede do Departamento de Defesa norte-americano. Era o auge da Guerra
Fria, e os cientistas queriam uma rede que continuasse on-line caso houvesse um ata-
que do tipo bombardeio.
Surgiu então o conceito central da Internet: uma rede em que todos os pontos se
equivalem e não há um comando central. Assim, se B deixa de funcionar, A e C con-
tinuam podendo se comunicar.
O nome Internet propriamente dito surgiu bem mais tarde, quando a tecnologia da
ARPAnet passou a ser usada para conectar universidades e laboratórios, primeiro
nos Estados Unidos e depois em outros países.
Por isso, não há um único centro que governa a Internet. Hoje ela é um conjunto
de mais de 40 mil redes no mundo inteiro. O que essas redes têm em comum é o pro-
tocolo TCP/IP (Transmission Control Protocol/Internet Protocol), que permite que elas
se comuniquem umas com as outras. Esse protocolo é a língua comum dos computa-
dores que integram a Internet.
Então, a Internet pode ser definida como:
uma rede de redes baseadas no protocolo TCP/IP;

uma comunidade de pessoas que usam e desenvolvem essas redes;
uma coleção de recursos que podem ser alcançados através dessas redes.
Durante cerca de duas décadas, a Internet ficou restrita ao ambiente acadêmico e

científico. Em 1987, pela primeira vez, foi liberado seu uso comercial nos Estados
Unidos. Mas foi em 1992 que a rede deu aquele boom. Começaram a aparecer nos
Estados Unidos várias empresas provedoras de acesso à Internet. Centenas de milha-
res de pessoas começaram a disponibilizar informações na Internet, que se tornou
uma mania mundial.

O Projeto World Wide Web – a Web

A Web nasceu em 1991 no laboratório CERN, na Suíça. Seu criador, Tim Ber-
ners-Lee, a concebeu apenas como uma linguagem que serviria para interligar com-
putadores do laboratório e outras instituições de pesquisa e exibir documentos cien-
tíficos de forma simples e fácil de acessar.
A Web fez sucesso rapidamente. Em 1993, já era comum em universidades que estu-
dantes fizessem páginas com informações pessoais. O que determinou seu crescimento
foi a criação de um programa chamado Mosaic, que permitia o acesso à Web em um am-
biente gráfico, tipo Windows. Antes do Mosaic só era possível exibir textos na Web.
Atualmente, a Web é o segmento da Internet que mais cresce. A antiga interface
da rede praticamente só é usada agora por universidades e institutos de pesquisa, e
mesmo assim, ela continua cada vez mais dando lugar à Web.
A chave do sucesso da World Wide Web é o hipertexto. Os textos e imagens são in-
terligados através de palavras-chave, tornando a navegação simples e agradável. A anti-
ga Internet, antes da Web, exigia do usuário disposição para aprender comandos em
Unix (linguagem de computador usada na Internet) um pouco complicados e para en-
frentar um ambiente pouco amigável, unicamente em texto. A Web fez pela Internet o
que o MAC OS e o Windows fizeram (e ainda fazem) pelo computador pessoal.
Os endereços Web sempre se iniciam com http:// (http significa Hipertext
Transfer Protocol ou protocolo de transferência de hipertexto). Para saber mais so-
bre a Web, visite o WWW Consortium no URL: www.w3.org.
O Projeto Internet no Brasil

Impossível falar sobre Internet no Brasil e não citar as importantes iniciativas de al-
guns órgãos públicos e instituições como o Ministério da Ciência e Tecnologia, Mi-
nistério da Educação, CNPq, FINEP, FAPESP, FAPERJ, FAPERGS e RNP. Farei
uma breve apresentação sobre a RNP e, em seguida, veremos como foi conduzido o
projeto Internet no Brasil.
A Associação Rede Nacional de Ensino e Pesquisa (RNP), instituição civil sem fins
lucrativos, foi constituída em 1999 para suceder o projeto RNP, criado em 1989
pelo Ministério da Ciência e Tecnologia e vinculado ao Conselho Nacional de Desenvol-
vimento Científico e Tecnológico (CNPq), com o objetivo de criar uma infra-estrutura
de rede acadêmica nacional. Em 2002, a RNP foi qualificada pelo governo federal
como uma Organização Social.
Em 1991, a RNP deu início à introdução da tecnologia Internet no país e vem de-
sempenhando, desde então, um papel de destaque na consolidação do backbone na-
cional para a comunidade acadêmica, na disseminação de serviços e aplicações para a
Internet e na capacitação de recursos humanos.
Atualmente, a RNP conecta os 27 estados brasileiros, interligando dezenas de mi-
lhares de computadores em mais de 300 instituições em todo o país. Diversos cen-
tros de pesquisa e instituições de ensino superior fazem uso intensivo da Internet

CAPÍTULO 1 57
através dos serviços da RNP. O modelo de prestação de serviços de redes operado

pela RNP foi concebido para dar suporte à introdução da tecnologia de redes Inter-
net no país, bem como sua difusão e sua capilaridade através do apoio à implantação
de redes estaduais no país.
A partir de 2000, a RNP passa a operar eminentemente como uma rede para ensi-
no e pesquisa, atendendo não só ao desenvolvimento de pesquisas (pós-graduação),
mas também às atividades de ensino e extensão. Essa nova rede interliga todas as
Instituições Federais de Ensino Superior (IFES) e Institutos de Pesquisa Federais
através do Programa Interministerial de Implantação e Manutenção da Rede Nacio-
nal para Ensino e Pesquisa, parceria firmada em outubro de 1999 entre o MCT e o
MEC, com duração até 2004. Esse programa assegura os recursos necessários ao cus-
teio da infra-estrutura nacional em operação atualmente e, sobretudo, viabiliza os
investimentos necessários à sua evolução tecnológica (RNP2) a fim de dar suporte às
novas aplicações de Internet2.
Desse modo, a Rede Nacional de Ensino e Pesquisa tem como objetivo principal a
implantação de um serviço de redes Internet para a comunidade de ensino e pesquisa
que atenda aos seguintes requisitos:
alta qualidade para o tráfego de produção Internet;
suporte a aplicações de educação superior, em especial, Bibliotecas Digitais;
interligação das redes metropolitanas de alta velocidade (ReMAVs) para expe-
rimentos de novas aplicações em longa distância.
A adequação tecnológica do novo bakcbone, RNP2, permitirá atender às aplica-
ções previstas pelo MEC e pelo MCT de forma eficiente, pois integrará na mesma in-
fra-estrutura dois tipos de serviços de rede:
Backbone para produção em que estarão conectadas todas as IFES (Instituições Fe-
derais de Ensino Superior) indicadas pela SESu (Secretaria de Educação Supe-
rior do MEC) e os Institutos de Pesquisa do MCT/CNPq, além das agências e
órgãos dos dois ministérios.
Backbone para experimentação com tecnologia ATM com capacidade para dar su-
porte às aplicações avançadas Internet2, incluindo bibliotecas digitais, ensino e
conferências à distância, entre outras. Além de interligar as principais Redes Me-
tropolitanas de Alta Velocidade (REMAVs), atualmente em fase de implantação,
e estabelecer enlaces de alta velocidade para os Estados Unidos, a fim de integrar
o Brasil ao projeto Internet2 e outras iniciativas da Europa, Ásia e Mercosul.
A disponibilidade dessa infra-estrutura é um marco estratégico para o suporte ao Pro-

grama da Sociedade da Informação, iniciativa do MCT que tem como foco a utilização
das tecnologias da informação para o desenvolvimento. A proposta desse programa mul-
tiinstitucional, ainda em preparação, é impulsionar a utilização das tecnologias da infor-
mação no país, com forte articulação entre os setores público, privado e acadêmico.

A Internet no Brasil
Em 1988, já se formavam no Brasil alguns embriões independentes de redes, interli-
gando grandes universidades e centros de pesquisa do Rio de Janeiro, São Paulo e
Porto Alegre aos Estados Unidos. Com o objetivo de integrar esses esforços e coor-
denar uma iniciativa nacional em redes no âmbito acadêmico, o Ministério da Ciên-
cia e Tecnologia formou um grupo composto por representantes do CNPq, da
FINEP (Financiadora de Estudos e Projetos), da FAPESP (Fundação de Amparo à
Pesquisa do Estado de São Paulo), da FAPERJ (Fundação de Amparo à Pesquisa do
Estado do Rio de Janeiro) e da FAPERGS (Fundação de Amparo à Pesquisa do Estado
do Rio Grande do Sul) para discutir o tema.
Como resultado, surge o projeto da RNP, formalmente lançado em setembro de
1989. No ano seguinte, o desafio principal foi estruturar a iniciativa de forma organiza-
da e definir claramente sua linha de ação. Determinou-se que sua atuação seria limitada
ao âmbito federal (interestadual) e internacional, sendo que, nos estados, iniciativas de
redes estaduais seriam estimuladas para a ampliação da capilaridade da rede.
O período de 1991 a 1993 foi dedicado à montagem da chamada Espinha Dorsal
(backbone) Fase I da RNP. Em 1993, a RNP já atendia a onze estados do país, com
conexões dedicadas a velocidades de 9,6 a 64 Kbps. Em paralelo à implantação de sua
estrutura, a RNP dedicou-se a tarefas diversas, tais como divulgar os serviços Inter-
net à comunidade acadêmica através de seminários, montagem de repositórios te-
máticos e treinamentos, estimulando a formação de uma consciência acerca de sua
importância estratégica para o país.
A partir de 94, com o grande aumento de instituições conectadas à rede, ampliou-se
a demanda sobre o backbone do Projeto. Paralelamente, percebeu-se que aplicações
interativas não eram viáveis a velocidades inferiores a 64Kbps. Assim, o período de 94
a 96 foi dedicado à montagem da Espinha Dorsal Fase II da RNP, com uma in-
fra-estrutura bem mais veloz que a anterior. A RNP firmou-se como referência em
aplicação da tecnologia Internet no Brasil, oferecendo apoio ao surgimento e desenvol-
vimento de variadas iniciativas de redes estaduais. Em maio de 1995, deu-se início à
abertura da Internet comercial no país. Nesse período, a RNP passou por uma redefi-
nição de seu papel, deixando de ser um backbone restrito ao meio acadêmico para es-
tender seus serviços de acesso a todos os setores da sociedade. Com essa reorientação
de foco, a RNP ofereceu um importante apoio à consolidação da Internet comercial no
Brasil. Foi criado o Centro de Informações Internet/BR para apoiar o surgimento de
provedores e usuários da Rede, que atendeu a mais de 3.000 questões relativas à Inter-
net em seu primeiro ano de funcionamento. Com relação ao financiamento do Proje-
to, especialmente a partir desse ano, inúmeras empresas fabricantes de bens de infor-
mática, como Compaq, Equitel, IBM, Philips etc., passaram a oferecer apoio concreto
à RNP, fornecendo equipamentos, software e até financiando atividades diretas do
projeto. A partir de 1995, o Brasil vem, então, registrando taxas extremamente altas
de crescimento no uso da Internet; taxas até superiores à média mundial.

CAPÍTULO 1 59
Entre os anos de 1996 e 1998, a RNP obteve consideráveis melhorias em sua infra-es-
trutura, ampliando a capilaridade e a velocidade de suas linhas. A partir do lançamento do
edital Projetos de Redes Metropolitanas de Alta Velocidade, em outubro de 1997, a RNP deu
início à terceira fase do projeto, denominada RNP2. O objetivo era incentivar o desen-
volvimento de uma nova geração de redes Internet, interligando todo o país em uma
rede acadêmica de alto desempenho e conectando-se à iniciativa norte-americana Inter-
net2. Nesse sentido, firmou-se um acordo de cooperação – MoU – entre a RNP e a
UCAID, entidade que coordena o projeto Internet2 nos Estados Unidos.
Em maio de 2000, o ministro da Ciência e Tecnologia, Ronaldo Mota Sarden-
berg, inaugurou o novo backbone RNP2, o qual atinge os 27 estados da federação
com capacidade de conexão de até 155 Mbps. A conexão à Internet2 foi estabelecida
em agosto de 2001 através de um canal de 45 Mbps, cedido pelo projeto AMPATH.
Desde janeiro de 2001 a RNP opera um link internacional de 155 Mbps, que será co-
nectado ao principal backbone da Internet2, o Abilene.
Na Figura 1.2, temos o Mapa do Backbone, mostrando a abrangência do RNP2 e de-
talhes sobre sua infra-estrutura.
F I G U R A 1 . 2 Mapa do Backbone RNP2

Mais informações sobre a RNP e a evolução da Internet brasileira podem ser aces-
sadas no URL: www.rnp.br.
Na seqüência, veremos outros adventos e contribuições importantes para a histó-
ria evolutiva do gerenciamento de projetos, dos quais se destacam o diagrama de
Gantt, os diagramas de rede, a concepção e a introdução do uso de software para au-
xiliar no gerenciamento de projetos.
O diagrama de Gantt
Em 1917 Henry Gantt desenvolveu o famoso diagrama de Gantt como uma ferra-
menta de agendamento de atividades. Gerentes desenhavam diagramas à mão para
mostrar como as tarefas deveriam ser realizadas considerando os prazos estabeleci-
dos no cronograma. Essa ferramenta forneceu um padrão para o planejamento e re-
visão de todo trabalho necessário nos primeiros projetos militares.
Hoje em dia, com a ajuda da tecnologia da informação, os gerentes de projetos ainda
utilizam o diagrama de Gantt como ferramenta para comunicar as informações do cro-
nograma do projeto, porém, com o advento do computador, não é mais necessário de-
senhar os gráficos à mão. Na Figura 1.3 temos um exemplo de gráfico de Gantt.
Os diagramas de redes
Diagramas de rede foram usados pela primeira vez em 1958 pela Marinha. Esses dia-
gramas ajudavam os gerentes de projeto a modelar os relacionamentos entre as tare-
fas do projeto, permitindo criar cronogramas mais realísticos.
F I G U R A 1 . 3 Exemplo de Diagrama de Gantt

CAPÍTULO 1 61
Note que nesse tipo de diagrama são incluídas setas que mostram como as tarefas
se relacionam e a seqüência em que devem ser realizadas.
A Figura 1.4 ilustra o uso do diagrama de rede no aplicativo Pert Chart Expert.
F I G U R A 1 . 4 Exemplo de Diagrama de Rede
Gerenciamento de projetos a partir da década de 1970

Na década de 1970, os militares começaram a utilizar software para ajudá-los a ge-
renciar grandes projetos. Esses aplicativos tinham um alto custo por serem os pri-
meiros que surgiram na época e por serem executados em mainframes (computado-
res de grande porte).
O Artemis foi um dos primeiros programas utilizados no gerenciamento de proje-
tos que permitiam fazer análises complicadas de cronograma para o desenho de caças
aéreos.
Passaram-se os anos e os computadores foram diminuindo de tamanho, seus siste-
mas operacionais tornaram-se mais intuitivos com interfaces amigáveis; aplicativos
gráficos de gerenciamento de projetos foram sendo desenvolvidos e ficaram mais
acessíveis em termos de preços. Dessa forma, mais pessoas tiveram acesso a esse tipo
de aparato tecnológico e ferramental de software para auxiliar no gerenciamento de
projetos.

Gerenciamento de projetos nos dias atuais

Como vimos, a indústria militar teve uma significante parcela de contribuição para o
desenvolvimento das teorias, dos conceitos e de muitas técnicas de gerenciamento
de projetos utilizados nos dias de hoje, além de ter promovido o importante advento
da Internet.
Diferentes tipos de indústrias utilizam metodologias de gerenciamento de proje-
tos e software de apoio na gestão de projetos, independentemente de serem peque-
nas, médias ou grandes corporações.
Os novos aplicativos tornam praticamente automática a criação de gráficos de
Gantt e diagramas de rede à medida que as tarefas vão sendo inseridas e seqüenciadas,
além de oferecerem uma infinidade de recursos que ajudam os gerentes de projetos e
toda equipe na automatização de várias tarefas, facilitando, por exemplo, os proces-
sos de comunicação de todos os envolvidos no projeto. Alguns exemplos desses apli-
cativos serão abordados no Capítulo 11.
Agora que já temos o conceito de projeto e sabemos um pouco sobre a história
evolutiva do gerenciamento de projetos, temos os alicerces necessários para com-
preender o conceito de gerenciamento de projetos.
O que é gerenciamento de projetos?

De acordo com o PMBOK – Terceira Edição, Gerenciamento de Projetos “é a aplicação
de conhecimentos, habilidades, ferramentas e técnicas nas atividades do projeto a
fim de atender aos requisitos do projeto”.
Esse conceito é melhor compreendido através dos grupos de processos que o
compõem: Iniciação, Planejamento, Execução, Controle e Encerramento – e em
nove áreas do conhecimento.
Atender aos requisitos do projeto envolve o balanceamento das seguintes deman-
das conflitantes:
Escopo, tempo, custo, risco e qualidade do projeto.
Satisfação de diferentes interessados (stakeholders) com diversas necessidades e
expectativas.
Requisitos identificados (necessidades) e requisitos não-identificados (expec-
tativas).
O ponto principal desse conceito é o controle. Não é possível atender aos requisi-
tos do cliente se não houver controle. O objetivo do gerenciamento de projetos é ga-
rantir o cumprimento do escopo, dos prazos, dos custos e da entrega dos produtos
com a qualidade esperada pelo cliente.
Os elementos-chave do gerenciamento de projetos

Os elementos-chave do gerenciamento de projetos são stakeholders, áreas de conhe-
cimentos, ferramentas de gerenciamento e técnicas.

CAPÍTULO 1 63
Stakeholders são todos os indivíduos envolvidos e afetados pelas atividades do pro-

jeto, e incluem o patrocinador (sponsor) do projeto, o gerente do projeto, a equipe
que vai implementar ou desenvolver o produto ou serviço do projeto, os clientes e os
usuários. Saber gerenciar as necessidades e as expectativas dos stakeholders do come-
ço ao fim do ciclo de vida do projeto é um fator de sucesso. Gerentes de projetos de-
vem trabalhar em sintonia com todos os stakeholders para garantir que suas expectati-
vas e necessidades sejam atendidas.
As áreas do conhecimento descrevem as competências-chave que os gerentes de pro-
jetos devem desenvolver. O PMBOK divide essas áreas em nove, a saber: gerencia-
mento da integração, gerenciamento do escopo, gerenciamento do tempo, geren-
ciamento do custo, gerenciamento da qualidade, gerenciamento dos recursos huma-
nos, gerenciamento das comunicações, gerenciamento dos riscos e gerenciamento
das aquisições do projeto.
As quatro áreas centrais do gerenciamento de projetos incluem o escopo, o tem-
po, os custos e a qualidade. Elas são consideradas centrais porque lidam diretamente
com os objetivos do projeto.
As quatro áreas facilitadoras do gerenciamento de projetos são os recursos huma-
nos, as comunicações, os riscos e as aquisições do projeto. Elas são consideradas faci-
litadoras porque são os meios de se alcançar os objetivos do projeto.
A área de gerenciamento da integração tem como função garantir que todas as ou-
tras áreas sejam integradas como um todo, e permite estruturar o projeto de modo a
garantir que as necessidades dos envolvidos sejam atendidas. Gerentes de projetos
devem ter conhecimentos e habilidades nas nove áreas para uma gerência efetiva.
As ferramentas e técnicas ajudam os gerentes de projetos e suas equipes a conduzir
melhor o escopo, o tempo, os custos e a qualidade. Ferramentas adicionais ajudam os
gerentes a controlar os recursos humanos, as comunicações, os riscos, as aquisições e
a integração das áreas de conhecimento do projeto. No decorrer deste livro veremos
alguns exemplos de ferramentas que auxiliam os gerentes de projeto.
Como o gerenciamento de projetos se relaciona com outras disciplinas

A maior parte do conhecimento necessário para gerenciar projetos é única da disci-
plina de gerenciamento de projetos. No entanto, os gerentes de projeto também de-
vem ter conhecimentos e experiência em gerenciamento geral e conhecer bem a
área de aplicação do projeto. Exemplificando, se o escopo do projeto é desenvolver
uma aplicação para automatizar a área de vendas de uma organização, então o geren-
te de projeto deve ter conhecimentos de processos e metodologias de vendas e soft-
ware de automação comercial, e, em alguns casos, pode necessitar de tecnologias e
conhecimentos de e-commmerce.
Embora ser um gerente de projetos requeira conhecimento e experiência em ge-
renciamento geral, sua função é diferente da função de um gerente corporativo ou
dos altos executivos da empresa. O que diferencia o gerenciamento de projetos de

operações gerais de gerenciamento é a natureza dos projetos. Já que os projetos são

únicos, temporários e envolvem vários recursos, os gerentes de projetos focam seus
esforços no sentido de integrar todas as atividades necessárias para cumprir com su-
cesso o objetivo do projeto.
Ao contrário, as atividades de um gerente geral são repetitivas e realizadas como
atividades diárias rotineiras. Por exemplo, um gerente de contabilidade canaliza o
seu gerenciamento nos aspectos dos controles contábeis da empresa. Se um geren-
te de projetos for escolhido para gerenciar um projeto de tecnologia da informação
no departamento de contabilidade, então, é recomendável que ele conheça ambas
as disciplinas, contabilidade e TI, e trabalhe em conjunto com o Controller da orga-
nização.
Benefícios do gerenciamento de projetos

Inúmeros são os benefícios estratégicos que o gerenciamento de projetos oferece
para as empresas.
Vargas destaca os seguintes:
Evita surpresas durante a execução dos trabalhos.

Permite desenvolver diferenciais competitivos e novas técnicas, uma vez que
toda a metodologia está sendo estruturada.
Antecipa as situações desfavoráveis que poderão ser encontradas, para que
ações preventivas e corretivas possam ser tomadas antes de essas situações se
consolidarem como problemas (proatividade).
Adapta os trabalhos ao mercado consumidor e ao cliente.
Disponibiliza os orçamentos antes do início dos gastos.
Agiliza as decisões, já que as informações estão sendo estruturadas e disponibili-
zadas.
Aumenta o controle gerencial de todas as fases a serem implementadas devido
ao detalhamento ter sido realizado.
Facilita e orienta as revisões da estrutura do projeto que forem decorrentes de
modificações no mercado ou no ambiente competitivo, melhorando a capaci-
dade de adaptação do projeto.
Otimiza a alocação de pessoas, equipamentos e materiais necessários.
Documenta e facilita as estimativas para futuros projetos.
Sunny Baker ressalta que “nenhum empreendimento pode ser considerado tão pe-
queno que não se beneficie do gerenciamento de projetos”.
Outros benefícios do gerenciamento de projetos são:
Melhor controle financeiro e dos recursos humanos do projeto

Melhoria nas relações com os clientes

CAPÍTULO 1 65
Menor tempo de implementação

Menores custos
Margens de lucros maiores
Aumento na produtividade
Melhor coordenação da equipe
Pelos motivos supracitados as empresas que adotam as práticas de gerenciamento

de projetos se beneficiam e se tornam cada vez mais competitivas, destacam-se no
mercado e, principalmente, demonstram para os seus clientes que estão organizadas
de acordo com as práticas e metodologias reconhecidas internacionalmente para rea-
lizar projetos com qualidade, cumprindo o que foi prometido, dentro do que foi or-
çado e de acordo com o tempo previsto.
ESTUDO DE CASO7
OS ON-LINE & MOBILIDADE – UM PROJETO WAY TV

Resumo
Este estudo de caso apresenta um projeto prático de tecnologia móvel desenvolvido em 2005/2006 na
Way TV Belo Horizonte S/A, empresa prestadora de serviços de televisão e Internet por assinatura. A base
do conhecimento proposto é representada pelo conceito da mobilidade, uma revolução tecnológica do
século XXI, como é considerada por muitos especialistas. Inicialmente será apresentado um overview
das tecnologias de transmissão e dispositivos, que tornam possível a aplicação da mobilidade em siste-
mas corporativos, além de uma argumentação de fatores que motivam o uso de tais tecnologias. No se-
gundo momento, é objetivo deste estudo de caso, mostrar um caso prático desenvolvido na Way TV Belo
Horizonte, desde o processo de levantamento de requisitos do aplicativo intitulado OS ON-LINE, a criação
de protótipos por parte de fornecedores selecionados até uma metodologia proposta de avaliação des-
sas empresas. Abordarei também questões como a criação de gerenciamento do projeto pelo EGP da
empresa e seu acompanhamento. Por fim, o estudo de caso tratará dos benefícios trazidos pela implan-
tação do projeto e, finalmente, da avaliação das lições aprendidas com sua implementação.
Introdução
Permitir aos indivíduos comunicação a qualquer momento, em qualquer lugar, representa uma mu-
dança na forma como os seres humanos interagem. A dissociação da comunicabilidade com a neces-
sidade de dispositivos grandes ou de difícil porte faz dessas tecnologias o fator de ligação em tempo
real entre os indivíduos e o mundo a sua volta, afetando suas relações sociais, familiares, afetivas e
profissionais.
7 Colaboração: Way Brasil TV – Belo Horizonte: http://www.waybrasil.com.br/way/way_tv/

No âmbito corporativo as tecnologias móveis representam uma ferramenta fantástica de acesso

em tempo real às aplicações, permitindo tomadas de decisões imediatas, agilizando e melhorando
substancialmente a qualidade dos serviços prestados aos clientes.
Vislumbrando este horizonte de constante evolução das aplicações corporativas, principalmente
em direção à mobilidade, as corporações se deparam com uma série de desafios ao construir sua es-
tratégia de desenvolvimento de aplicações móveis. As agendas dos CIOs estão repletas de questões
sobre o assunto.
n
Por quais aplicações começar?
n
Qual dispositivo deve ser selecionado?
n
Qual rede é mais adequada?
n
Quais benefícios serão trazidos por esta tecnologia?
n
Quais tecnologias mais adequadas a cada tipo de negócio?
n
Como implementar aplicações móveis?
n
Quais as tecnologias mais promissoras?
n
Qual o impacto dessas tecnologias nas corporações ?
Estas são perguntas a serem respondidas para a viabilização e uso extensivo das tecnologias mó-
veis. Independentemente da forma como elas serão respondidas, o seu uso é caminho sem volta. A
mobilidade atingiu um patamar estratégico, intimamente ligado à produtividade e competitividade das
corporações. A disponibilidade de banda e tecnologias adequadas a cada tipo de negócio veio ao en-
contro das corporações, que cada vez mais querem se enquadrar no modelo das chamadas “Empre-
sas em Tempo Real”.
Mobilidade
Conceito
A demanda por interação em tempo real, não importando a localização física de quem necessita desta
interação, é aquilo que podemos chamar de diferencial da mobilidade. O conceito de “estação de tra-
balho” ou mesmo de “desktop” já não é suficiente para manter colaboradores de uma empresa com
acesso em tempo real. As tomadas de decisão e oportunidades de negócio requerem acesso imediato
em qualquer hora e lugar, com máxima flexibilidade, deixando o âmbito restrito da LANs, ou mesmo a
dependência de infra-estruturas baseadas em modelos estáticos.
Sendo assim, ao se tornarem móveis as ferramentas corporativas, rompe-se o laço que prendia o
executivo à infra-estrutura da empresa, criando a possibilidade de trabalhar em tempo real. A Mobili-
dade deixa de ser uma tendência para ser um imperativo de competitividade, amplamente suportado
pelo avanço tecnológico.
Por que investir em mobilidade?

Existem quatro fatores principais que justificam o investimento em mobilidade, por serem diferenciais
importantes em um mercado globalizado e competitivo. São eles:
n
A riqueza de informação – demandada por profissionais cada vez mais qualificados e ávidos por in-
formações enriquecidas e atualizadas, de forma ágil e interativa como as transações das corpora-
ções modernas.

CAPÍTULO 1 67
n
Facilidade de uso – as aplicações móveis tedem a ser simples e intuitivas no uso, com interfa-
ces gráficas aderentes a padrões de usabilidade, além de poderem estar embarcadas em dis-
positivos com comando de voz, com modelos de entrada e saída simplificados, primando pela
agilidade.
n
Facilidade de gerenciamento – um grande avanço trazido pelas tecnologias móveis é a rastrea-
bilidade. Acompanhar processos inerentes a organização, porém, executados externamente,
sempre foi um fator gerador de problemas. A Gestão de Presença é uma funcionalidade que as
aplicações móveis tendem a trazer como benefício imediato às empresas que as utilizam. Com
elas pode-se saber a localização dos colaboradores, além de acompanhar o status destes a
cada nova situação.
n
Imediatismo – com a aceleração das transações e a evolução das corporações rumo à gestão em
tempo real, o ciclo de vida da informação tem se encurtado significativamente. Este fato gera a ne-
cessidade de imediatismo no acesso instantâneo às aplicações e às informações que elas disponi-
bilizam, acessam e/ou processam.
Visão tecnológica
São muitas as tecnologias de conectividade capazes de dar a uma aplicação móvel acesso a uma rede
pública ou privada. Não faltam opções para a empresa implementar aplicações móveis.
Para entender as tecnologias em mobilidade é importante categorizá-las quando a abrangência
das redes.
n
Mobilidade indoor – consiste no deslocamento do profissional nas dependências da corporação.
Geralmente utiliza-se a tecnologia Wifi, sendo que o WiMax desponta também como uma boa op-
ção para este cenário;
F I G U R A 1 . 5 Tecnologias da Rede Móvel

n
Mobilidade urbana – refere-se ao uso de aplicações móveis em áreas metropolitanas. Uma boa op-
ção em termos de tecnologia para esta categoria é a rede Mesh Netwok Wifi. O WiMax representa
uma opção, também com a versão 802.16e (permite acesso em movimento).
n
Mobilidade global – é essencial especialmente a altos executivos ou grandes especialistas que ne-
cessitam de se comunicar em qualquer lugar. Neste caso, o mais adequado é o uso do roaming in-
ternacional às capacidades utilizadas na mobilidade urbana.
MOBILIDADE NA WAY TV
O Projeto OS ON-LINE
Motivação
Automatizar o processo de distribuição, acompanhamento de baixa de Ordem de Serviços, foi o fator
que levou a Way TV a procurar nas tecnologias de mobilidade uma solução que permitisse fornecer aos
seus assinantes de televisão e Internet um atendimento técnico ágil e eficaz.
O desenvolvimento desse projeto permitiria também, através da criação de um Móbile Middle-
ware, criar uma interface entre o Sistema de Habilitação de Serviços e o Módulo de Materiais do
ERP da empresa, gerando um controle em tempo real dos empregados ativos nos atendimentos
técnicos.
Requisitos
Para que o projeto se tornasse viável sob o ponto de vista técnico, foi desenvolvido um documento, em
parceria com o Departamento Técnico da empresa e a área de Tecnologia da Informação, denominado
“especificação de requisitos”. Neste, premissas indispensáveis à aplicabilidade do software a ser de-
senvolvido foram levantadas e registradas, com o propósito de se ter um escopo funcional do projeto a
ser desenvolvido.
O documento contemplou tantos os pontos de adequação do aplicativo às regras de negócio da
empresa quanto o modelo de infra-estrutura de TI.
A adequação ao SOA e ao AS da Oracle, em implantação na instituição, forçou a criação de restri-
ções ao novo desenvolvimento, principalmente no que diz respeito à plataforma de desenvolvimento
do software definida como sendo o JAVA, tanto para o aplicativo móvel quanto para os módulos Web do
sistema.
Como plataforma móvel, dispositivos celulares convencionais foram escolhidos. Levantamentos
iniciais apontaram para um baixo consumo de memória do aplicativo. Isso associado ao baixo custo
dos dispositivos resultou em fatores importantes na viabilização econômica do projeto como um todo.
Ao final obteve-se um escopo macro do projeto. O aplicativo deveria contemplar as seguintes funcio-
nalidades:
n
Disparo das ordens de serviço aos dispositivos móveis
n
Registro de cumprimento de etapas de atendimento
n
Consulta e aplicação de equipamentos e materiais em assinantes
n
Envio de materiais aplicados ao ERP
n
Monitoramento dos serviços em campo
n
Baixa de ordem de serviço e habilitação serviços
n
Auditoria

CAPÍTULO 1 69
Pilotando protótipos
Após a conclusão dos levantamentos e documentação dos requisitos do aplicativo, fez-se uma bus-
ca ao mercado. Empresas de desenvolvimento de soluções em mobilidade foram consultadas e con-
vidadas a participarem do processo de avaliação e contratação de parceiro para desenvolvimento
do software.
Cinco empresas se apresentaram. A cada uma foi entregue uma cópia do “especificação de requi-
sitos”, para que, através de recursos próprios e sem compromisso das partes, criasse um protótipo a
ser “pilotado” e avaliado pela Way TV.
Avaliação de fornecedores
Durante quatro meses, os cinco protótipos foram testados.
Para a avaliação da qualidade e adequação aos requisitos básicos do projeto, foi criado um método
de pontuação baseado em quesitos de qualidade do protótipo e do fornecedor.
Para isso criou-se uma escala de quesitos, pesos e pontuações, utilizadas pela equipe interna do
projeto, com o objetivo de avaliar as soluções e as empresas das quais elas originaram.
Foram definidos como quesitos de avaliação:
n
Consistência
n
Monitoramento
n
Tecnologia
n
Disponibilidade dos serviços de rede
n
Tempo de resposta do aplicativo
n
Operação do dispositivo móvel
n
Cobertura
n
Suporte de rede
n
Auditoria
n
Suporte de software
n
Estrutura da empresa
n
Localização e acesso
n
Referências
n
Prazos
Criação e gerenciamento do projeto

O Projeto OS ON-LINE coincidiu com a implantação na empresa do EGP, responsável pelo gerencia-
mento dos projetos que cumprissem determinados requisitos relativos a custo e prazo.
A anexação do projeto OS ON-LINE ao Escritório de Projetos da Way TV fez com que o projeto ga-
nhasse em estrutura, facilitando o seu acompanhamento em termos de recurso e tempo. Além disso,
foi um grande aprendizado para a empresa. Criou-se um modelo estrutural de projetos de desenvolvi-
mento de software ainda não existente no EGP. As boas práticas do PMI foram implementadas e
utilizadas no seu gerenciamento.

Avaliação dos Fornecedores

Empresa 1 Empresa 2 Empresa 3 Empresa 4 Empresa 5
Quesito Peso Avaliação Avaliação Avaliação Avaliação Avaliação
1a5 1a5 Pontos Pontos Pontos Pontos Pontos
1a5 1a5 1a5 1a5
Consistência 5 3 15 3 15 4 20 5 25 2 10
Monitoramento 5 3 15 4 20 3 15 4 20 3 15
Tecnologia 5 2 10 4 20 3 15 3 15 4 20
Disponibilidade Serviços 5 5 25 2 10 3 15 4 20 3 15
Tempo de Resposta 5 3 15 2 10 3 15 5 25 3 15
Operação Disp. Móvel 4 4 16 2 8 2 8 4 16 2 8
Cobertura 4 3 12 5 20 5 20 5 20 5 20
Suporte de Rede 4 4 16 3 12 3 12 3 12 3 12
Auditoria 3 3 9 2 6 0 0 1 3 1 3
Suporte de Software 3 4 12 3 9 4 12 4 12 3 9
Estrutura da Empresa 4 5 20 5 20 2 8 4 16 2 8
Localização e Acesso 4 5 20 1 4 4 16 4 16 5 20
Referências 5 5 25 4 20 1 5 4 20 4 20
Prazos 4 4 16 3 12 4 16 5 20 1 4
Pontuação Total 1 226 186 177 240 179
F I G U R A 1 . 6 Avaliação dos Fornecedores
Benefícios atingidos
Inicialmente era perspectiva para o projeto resultar nos seguintes benefícios:
n
Diminuir o tempo de atendimento aos assinantes.
n
Diminuir número de ligações telefônicas nos atendimentos.
n
Medir e controlar o consumo de materiais na execução de serviços.
n
Monitorar em tempo real os serviços executados pelos empreiteiros.
n
Auditar a qualidade dos serviços.
n
Diminuir o custo operacional nas transações envolvendo assinantes/materiais.
n
Aumentar a consistência das informações nas operações de transferência e aplicação de materiais.
n
Obter dados reais sobre os tempos de atendimento de OS.
n
Aumentar o grau de satisfação dos assinantes.
Na verdade, os benefícios foram um pouco além. Uma vez implementado, o projeto mostrou-se
uma grande surpresa para a empresa. Benefícios não previstos nos estudos de viabilidade foram iden-
tificados prontamente. As informações geradas pelo aplicativo acabaram por alimentar recursos im-
portantes de medição dos serviços da empresa, tanto em termos de logística como em apontar novas
direções para agilização dos serviços prestados.
A implantação do processo mudou de forma significativa as atividades da equipe interna da empresa.
Os colaboradores deixaram de executar tarefas operacionais de encerramento, passando a exercer fun-
ção de monitoramento e controle, ou seja, tarefas mais nobres, causando motivação a equipe.
Conclusão
O modelo estático das corporações está com os dias contados. Ser móvel se tornou sinônimo de ser
ágil, moderno e produtivo.

CAPÍTULO 1 71
Além de ter a informação em tempo real e obtê-la em qualquer lugar, é imperativo, em um mundo
altamente competitivo – movido cada vez mais pela integração dos sistemas, sejam eles horizontais
ou verticais da corporação –, ter a capacidade de lidar com informações em formatos convergentes
com as necessidades de nosso tempo.
Tempo em que a tecnologia deixou de ser um diferencial competitivo simplesmente pelo poder de
seduzir clientes e investidores para se tornar recurso de alta disponibilidade, vencendo as barreiras do
espaço físico onde estas estão lotadas, sob medida para o ambiente onde aqueles se aplicam, fazendo
do mundo da mobilidade, o mundo da eficácia.
O ambiente corporativo está definitivamente de volta à rodada de investimentos em tecnologia da
informação, e promete impelir fabricantes, desenvolvedores de aplicativos e integradores na eterna
busca de redução de custos e aumento de produtividade.
Pingarilho, Carlos e Faro, Luiz. “Mobilidade: a grande tendência do futuro”. Rio de Janeiro: Promon
Business & Technology Review, 2006.
Carvalho, Jackeline. “O escritório no bolso”. Revista Tiinside, São Paulo: Glasberg, n. 13, maio de
2006.
Tavares de Mattos, Érico. Programação Java para Wireless. São Paulo: Digerati Books, 2005.

CAPÍTULO 2
O contexto e os processos do
CONSIDERAÇÕES
Como tudo na vida, os projetos também estão inseridos num contexto específico e
são praticados através de ações coordenadas e gerenciadas para atingir um resultado.
Este capítulo descreve o contexto do projeto e apresenta uma introdução aos pro-
cessos da gerência de projetos. Apesar de serem genéricos, os conceitos apresenta-
dos se adequam e se aplicam aos projetos de tecnologia da informação.
CONTEXTO
Os aspectos que envolvem o contexto dos projetos são as fases e o ciclo de vida dos
projetos, os envolvidos no projeto, a influência das organizações, as principais habili-
dades do gerente de projetos e influências sócio-econômicas.
Fases e ciclo de vida dos projetos

Como já vimos, os projetos são empreendimentos únicos, nunca realizados. A carac-
terística de unicidade deve-se ao fato de os projetos possuírem inerentemente graus
de incerteza. Para um melhor controle gerencial dessas incertezas, dividimos a con-
dução do projeto em fases. O conjunto das fases do projeto é denominado ciclo de vida
do projeto.
Cada fase pode ter um conjunto de subprodutos para melhor controle do geren-
ciamento. Em projetos de tecnologia da informação, principalmente de desenvolvi-
mento de software, normalmente adotamos nomes como: levantamento de requisi-

tos, análise, implementação, codificação, testes, documentação, implantação, tran-

sição, suporte, entre outros.
Como o projeto tem o fator tempo limitado, o ciclo de vida também serve para defi-
nir início e fim do projeto, além de determinar o seqüenciamento das fases do projeto.
Os ciclos do projeto também definem o trabalho técnico a ser executado em cada
fase, as pessoas responsáveis por sua implementação, a quantidade de recursos hu-
manos e o custo associado a eles, além das tendências de sucesso do projeto.
Existe uma diferença entre ciclo de vida do projeto e ciclo de vida do produto. O
ciclo de vida de um produto passa geralmente pelos seguintes estágios: concepção,
produção, testes, implantação, lançamento, utilização, crescimento, maturidade,
declínio e morte.
Um produto pode, por exemplo, ter um ciclo de vida de dois anos; entretanto,
como foram gastos oito meses para a sua produção, considera-se que o ciclo de vida
total desse produto tenha sido de dois anos e oito meses.
O ciclo de vida dos produtos é ainda mais crítico em projetos de tecnologia da in-
formação, principalmente com as rápidas mudanças tecnológicas. O leitor poderá
encontrar mais detalhes sobre este assunto no Capítulo 4.
Os envolvidos no projeto
Os envolvidos no projeto, também denominados stakeholders, são as pessoas e as or-
ganizações diretamente ligadas ao projeto, ou aqueles indivíduos afetados pelo pro-
jeto, seja de forma positiva ou negativa. Esse envolvimento pode ocorrer em todas as
fases do ciclo de vida do projeto.
A equipe de gerência deve identificar todos os envolvidos no projeto antes de ini-
ciá-lo, conhecer as suas necessidades e expectativas e gerenciá-los de forma organi-
zada para assegurar o sucesso do projeto.
É claro que, no decorrer do projeto, outras pessoas poderão ser envolvidas; po-
rém, quanto mais cedo você identificá-las, melhor será para o gerenciamento das in-
terfaces do projeto.
Alguns dos envolvidos mais comuns no projeto são:
o dono (sponsor), ou patrocinador

o cliente
o gerente do projeto
a organização executora
os membros da equipe do projeto
Pessoas diferentes pensam de maneira diferente e possuem objetivos e expectati-

vas diferentes. Uma das tarefas mais desafiadoras de um gerente de projetos é saber
encontrar soluções adequadas para tais divergências e conflitos entre os envolvidos
no projeto.

O CONTEXTO E OS PROCESSOS DO GERENCIAMENTO DE PROJETOS
CAPÍTULO 2 75
Influência das organizações

Os projetos fazem parte das organizações, sem as quais não existiriam. Os projetos
estão sujeitos a sofrer algumas influências dependendo da forma como as organiza-
ções estão estruturadas.
A maturidade da organização em relação às metodologias de gerenciamento de
projeto adotadas, à cultura, ao estilo, à estrutura organizacional e ao emblema Escri-
tório de Projetos influencia diretamente a condução e o contexto do gerenciamento do
projeto.
Existem as organizações orientadas a projetos e as organizações não-orientadas a
projetos. As organizações orientadas a projetos são aquelas que dependem de proje-
tos para sobreviverem. Suas receitas são originadas essencialmente do desenvolvi-
mento de projetos para outras organizações. As organizações não-orientadas a proje-
tos são aquelas divididas por departamentos, nos quais são realizadas operações de
rotina.
As estruturas das organizações estão divididas em estruturas funcionais ou hie-
rárquicas, matriciais e projetizadas. As estruturas funcionais ou hierárquicas são
aquelas em que cada funcionário tem um superior bem definido, os membros das
equipes se reportam a esse superior e são agrupados por especialidades. Essas or-
ganizações também possuem projetos, porém existe uma independência muito
grande das chefias dos departamentos para executá-los. A Figura 2.1 ilustra esse
conceito.
Em uma organização com estrutura projetizada, a maioria dos recursos (ou todos
eles) está envolvida em projetos, e os gerentes de projeto são menos dependentes de
gerentes funcionais e possuem maior autoridade na organização. É comum essas or-
ganizações possuírem departamentos; porém, os recursos dos departamentos se re-
portam diretamente aos gerentes de projetos e podem fornecer serviços de suporte a
outros departamentos. A Figura 2.2 ilustra esse conceito.
CEO
Gerente Gerente
Gerente RH
Financeiro Técnico
Pessoal Pessoal Pessoal Pessoal
Pessoal Pessoal
F I G U R A 2 . 1 Estrutura Organizacional Funcional ou Hierárquica

CEO
Gerente de Gerente de Gerente de

Projetos Projetos Projetos
Pessoal Pessoal Pessoal Pessoal Pessoal
Pessoal Pessoal
Gerente de
Pessoal
Projetos
F I G U R A 2 . 2 Estrutura Organizacional Projetizada
A estrutura matricial é uma combinação de estruturas organizacionais funcionais

com estruturas organizacionais projetizadas. Existem dois tipos de estruturas matri-
ciais: fracas e fortes. As estruturas matriciais fracas mantêm muitas características da
organização com estrutura hierárquica, e o gerente de projeto funciona mais como
um coordenador do que como um gerente propriamente dito. Já as estruturas matri-
ciais fortes possuem gerentes de projeto, com autoridade considerável, dedicados à
gestão de projetos e de pessoal alocado. A Figura 2.3 ilustra esse conceito.
Outro tipo de estrutura interessante que vem sendo amplamente adotado e im-
plementado nas organizações é o que o PMBOK denomina PMO (Project Management
Office), ou Escritório de Projetos. O EP é responsável pelo constante provimento de
CEO
Gerente Gerente
Gerente RH
Financeiro Técnico
Pessoal Pessoal Pessoal
Pessoal Pessoal Pessoal
Gerente de
Pessoal Pessoal
Projetos
F I G U R A 2 . 3 Estrutura Organizacional Matricial

O CONTEXTO E OS PROCESSOS DO GERENCIAMENTO DE PROJETOS
CAPÍTULO 2 77
suporte aos gerentes de projetos através de treinamentos, workshops, palestras, es-

tabelecimento de padrões e indicação de software para gestão de projetos.
Principais habilidades do gerente de projetos

Para exercer o nobre papel de gestor de projetos, o gerente precisa de habilidades de
administração geral, tais como:
Liderança
Comunicação
Negociação
Solução de problemas
Influência na organização
Influências socioeconômicas e ambientais

A gerência do projeto deve estar muito alerta aos aspectos e influências socioeconô-
micos, já que as condições e tendências atuais do mercado refletem-se diretamente
nos projetos, causando impactos em diversas áreas. Tais mudanças podem gerar, por
exemplo, atrasos no cronograma ou alterações no custo do projeto.
Os gerentes de projetos devem acompanhar constantemente as notícias sobre os
cenários políticos e econômicos dos países nos quais os projetos são realizados.
Ações proativas podem ser tomadas nos projetos através da simples observação des-
ses fatos e tendências.
INTRODUÇÃO AOS PROCESSOS DE GERÊNCIA DE PROJETOS

Cada projeto é composto por uma série de processos, os quais possuem uma forte carac-
terística de interação. Quando falamos em processo, no fundo estamos falando de resul-
tados, porque processos são “uma série de ações (coordenadas) que geram um resultado”.
Os processos do projeto são executados por pessoas e podem ser divididos em
processos de gerência de projeto e processos orientados ao produto. Os processos de
gerência de projeto são aqueles que se relacionam com a descrição e com o planeja-
mento do escopo do projeto.
Processos orientados ao produto são aqueles relacionados aos requisitos, às espe-
cificações e à geração do produto do projeto. Os processos orientados ao produto
são definidos pelo ciclo de vida do projeto e podem ser divididos em cinco grupos:
iniciação, planejamento, execução, controle e encerramento.
Os processos de iniciação reconhecem formalmente e autorizam o início de um pro-
jeto ou de uma fase. É importante obter o comprometimento da organização para a
realização do projeto.
Os processos de planejamento definem e refinam os objetivos e as escolhas das melho-
res alternativas de ação para atingir os objetivos propostos pelo projeto.
Os processos de execução são responsáveis pela coordenação das pessoas e dos outros
recursos para realizar o que foi planejado.

Os processos de monitoramento e controle servem para garantir que os objetivos do

projeto sejam atingidos, através da monitoração freqüente do seu progresso, identi-
ficando alterações no que foi planejado. Caso essas alterações ocorram, ações proati-
vas e corretivas são tomadas.
Os processos de encerramento têm a função de formalizar a aceitação do projeto ou da
fase e encerrá-lo(a) organizadamente.
Os grupos de processos são interligados através dos resultados que cada um pro-
duz. Além disso, os grupos de processos não podem ser vistos de forma separada ou
descontínua, e nem acontecem apenas uma vez durante o ciclo de vida do projeto.
O que determina a forte interação entre os processos são as suas entradas, ferra-
mentas e técnicas e saídas. As entradas são documentos ou itens que terão uma forte
influência no processo.
As ferramentas e técnicas são mecanismos e ferramentas aplicados às entradas
que, depois de avaliadas e processadas, serão transformadas em saídas. As saídas são
os documentos ou itens passíveis de documentação, resultantes de todo o processo.
No PMBOK os processos estão inseridos e organizados de acordo com as suas res-
pectivas áreas do conhecimento, do Capítulo 4 ao Capítulo 12; e são identificados
por um número entre parênteses (X.Y), onde X representa o capítulo e Y a seção. Os
processos são divididos em cinco grupos: Iniciação, Planejamento, Execução, Moni-
toramento e Controle e Encerramento.
A Figura 2.4 ilustra como os grupos de processos interagem.
No próximo capítulo, veremos outros aspectos aos quais o gerente de projeto
deve estar atento.
Processos de Processos de
Iniciação Planejamento
Processos de Processos de
Controle Execução
Processos de
Finalização
F I G U R A 2 . 4 Interação dos Grupos de Processos

CAPÍTULO 3
O gerente de
projetos antenado
INTRODUÇÃO
O gerente de projetos deve estar atento a uma série de aspectos que permeiam o pro-
jeto, de modo que ele possa exercer sua função e evoluir nas práticas de seu nobre pa-
pel de gestor.
Este capítulo aborda alguns conceitos e tendências afins à matéria gerenciamento
de projetos. Serão apresentados alguns aspectos relevantes sobre o gerenciamento
da qualidade, dos recursos humanos, dos custos, tributos, gestão de riscos, Seis Sig-
ma e a apresentação da metodologia UPMM, além da abordagem do IIL para a capa-
citação em gerenciamento de projetos, baseada no Enfoque Kerzner para Excelência
em Gerenciamento de Projetos.
GERENCIAMENTO DA QUALIDADE
Neste tópico veremos dois assuntos: gerenciamento moderno da qualidade e outros
métodos para ajudar na qualidade dos projetos, sejam eles de tecnologia da informa-
ção ou de outras naturezas.
No gerenciamento moderno da qualidade apresentarei contribuições conceituais
e empíricas de alguns dos maiores especialistas internacionais do assunto, responsá-
veis pela evolução dos sistemas de controle de qualidade que temos atualmente.
Serão abordados também assuntos como o comprometimento da alta gerência, o
custo da qualidade, os aspectos relacionados ao ambiente de trabalho e os modelos de
maturidade.

A evolução do gerenciamento moderno da qualidade

Algumas pessoas, incluindo W. Edwards Deming, Joseph M.Juram, Philip B. Crosby,
Kaoru Ishikawa, Genichi Taguchi e Armand V. Feigenbaum, deram grandes parcelas
de contribuição para o desenvolvimento do moderno gerenciamento da qualidade.
O Dr. W. Edwards Deming é conhecido por seu trabalho de controle de qualida-
de no Japão. Deming foi para o Japão depois da Segunda Guerra Mundial a pedido do
governo japonês para ajudá-los a melhorar a produtividade e a qualidade. Na década
de 1980, depois de terem visto os excelentes resultados do trabalho do Dr. no Japão,
organizações dos Estados Unidos solicitaram a expertise de Deming para ajudá-los
em seus programas de controle de qualidade. Muitas pessoas conhecem o Prêmio De-
ming, um prêmio de reconhecimento de organizações com alta qualidade, e o Ciclo de
Melhoria de Deming: planejar, fazer, verificar e agir. Existem também os 14 Pontos
de Gerenciamento de Deming sumarizados a seguir:
1. Ter o propósito de criar constantemente melhorias de produtos e serviços.
2. Adotar novas filosofias.
3. Ficar menos dependente de inspeção para alcançar a qualidade.
4. Minimizar o custo total trabalhando com poucos fornecedores.
5. Melhorar constantemente os processos de planejamento, produção e serviço.
6. Promover a aquisição de experiências no ambiente de trabalho.
7. Adotar e instituir a liderança.
8. Não ter medo.
9. Quebrar as barreiras de pessoal entre os departamentos da organização (in-
tegração).
10. Evitar slogans.
11. Evitar cotas numéricas para a força de trabalho e objetivos numéricos para o
gerenciamento.
12. Remover as barreiras que impeçam as pessoas de serem habilidosas e criativas.
13. Instituir um vigoroso programa de educação e autodesenvolvimento para
todos.
14. Colocar todos na organização para serem agentes de mudanças.
Referências bibliográficas e links na Internet sobre W. Edwards Deming

Livros
Out of the Crisis. MIT Press 1986.
The New Economics for Industry, Government, Education, 2a edição Massachussets: MIT Press, 2001.
Least Squares, The Graduate School, Department of Agriculture, Washington 1938.
Statistical Adjustment of Data. Nova York: John Wiley and Sons, 1943, Dover 1964.
Some Theory of Sampling. Nova York: John Wiley and Sons, 1950.
Elementary Principles of the Statistical Control of Quality. Tokyo: Nippon Kagaku Gijutsu Renmei,
1950-52.
Sample Design in Business Research. Nova York: John Wiley and Sons, 1960.

O GERENTE DE PROJETOS ANTENADO
CAPÍTULO 3 81
The W. Edwards Deming Institute
http://www.deming.org/
Sites
Deming Electronic Network
http://deming.ces.clemson.edu/pub/den/
American Statistical Association
http://www.amstat.org/
The Deming Cooperative
http://deming.edu/demingcoop.html
Joseph M. Juran, assim como Deming, ajudou fábricas japonesas, ensinando-lhes

como melhorar a produtividade. Mais tarde, ele também foi descoberto por organiza-
ções dos Estados Unidos e escreveu a primeira edição do Quality Control Handbook em
1974, explorando a fundo a importância do comprometimento da alta gerência para o
contínuo desenvolvimento da melhoria da qualidade. Em 1999, escreveu a quinta edi-
ção do seu famoso Handbook. Também desenvolveu a Trilogia de Juran: melhoria da
qualidade, planejamento da qualidade e controle da qualidade. Juran expôs com deta-
lhes a diferença entre a visão de qualidade do fabricante e a visão de qualidade do clien-
te. Para ele, os fabricantes geralmente se concentram na aderência de especificações do
produto, enquanto o cliente se concentra na aderência do uso do produto.
A maioria das definições de qualidade atuais utiliza a aderência do uso do produto
para demonstrar a importância da satisfação ou as necessidades implícitas alcançadas,
e não somente o alcance dos requisitos ou especificações de produção.
Juran desenvolveu dez passos da melhoria da qualidade, descritos a seguir:
1. Promova a consciência da necessidade e oportunidade de melhorias.
2. Estabeleça metas para a melhoria.
3. Organize-se para alcançar as metas (estabeleça um conselho de qualidade,
identifique os problemas, selecione projetos, designe equipes e facilitadores).
4. Forneça treinamentos.
5. Realize projetos para resolver problemas.
6. Reporte o progresso.
7. Reconheça os esforços.
8. Comunique os resultados.
9. Fique de olho nos resultados.
10. Faça melhorias anuais nos sistemas e processos da organização.
Referências bibliográficas e links na Internet sobre Joseph M. Juran

Livros
Architect of Quality. Nova York, McGraw-Hill, 2003.
Juran Institute’s Six Sigma Breakthrough & Beyond, Nova York, MacGraw-Hill, 2003.
Juran on Leadership for Quality. Nova York, Freepress, 1989.

Juran’s Planning & Analysis for Enterprise Quality, MacGraw-Hill Science/Engineering/Math, 2005.
Juran’s Quality Handbook, 5a edição, Nova York, MacGraw-Hill, 1998.
Quality Benchmarks for Executives.
Quality Control Handbook, 1951, Nova York, MacGraw-Hill, 1988.
Planning and Practices in Quality Control. Nova York, MacGraw-Hill. Japanese Union of Scientists and
Engineers, 1954.
Managerial Breakthroughs, Nova York, MacGraw-Hill, 1964.
Quality By Design, Nova York, The Free Press , 1992.
A History of Managing for Quality, Milwawke, Wiss, ASQC Quality Press.
Sites
Juran Institute
http://www.juran.com/
Quality Gurus-Joseph Juran
http://qualitygurus.com/gurus/list-of-gurus/joseph-juran/
Discussion on the Pareto Principle
http://elsmar.com/Forums/archive/index.php/t-6219.html
CSQA professionals site
http://www.csqa.info/drp/
Philip B. Crosby escreveu Quality Is Free em 1979 e é mais conhecido por ter suge-
rido que as organizações poderiam aspirar defeitos zero. Para ele, os custos de pouca
qualidade devem incluir todos os custos de não fazer o trabalho correto da primeira
vez. Crosby desenvolveu 14 passos para a melhoria da qualidade:
1. Certifique-se de que a gerência esteja comprometida.
2. Forme times de melhoria de qualidade com representantes de cada departa-
mento.
3. Determine onde os problemas atuais de qualidade residem.
4. Avalie os custos da qualidade e justifique-os como uma ferramenta gerencial.
5. Aumente a consciência da qualidade em todos os funcionários.
6. Tome ações para corrigir problemas identificados através de ações prévias
(proatividade).
7. Estabeleça um comitê para um programa de defeito zero.
8. Treine os supervisores para efetivamente conduzirem suas responsabilida-
des do programa de melhoria da qualidade.
9. Institua um “Dia de Defeito Zero”.
10. Encoraje os indivíduos a estabelecer metas de melhorias para si mesmos e
para seus grupos.
11. Encoraje os funcionários a comunicar à gerência os obstáculos encontrados
que os impeçam de alcançar as melhorias de qualidade.
12. Reconheça e elogie as pessoas que participam.
13. Estabeleça conselhos de qualidade para fornecer informações regularmente.
14. Enfatize que o programa de melhoria da qualidade nunca acaba.

CAPÍTULO 3 83
Referências bibliográficas e links na Internet sobre Philip B. Crosby

Livros
Quality is free: the art of making quality certain. Nova York: McGraw-Hill, 1979.
Quality Without Tears: The Art of Hassle-Free Management, Nova York: MacGraw-Hill, 1984.
The Eternally Successful Organization: The Art of Corporate Wellness, Nova York: MacGraw-Hill, 1988.
Quality and Me: Lessons from an Evolving Life, Nova York: MacGraw-Hill, 1999.
Sites
Quality Gurus: http://qualitygurus.com/gurus/list-of-gurus/philip-crosby/
Philip Crosby’s Essays and Writings: http://www.wppl.org/wphistory/PhilipCrosby/grant.htm
Biography at the Philip Crosby website: http://www.philipcrosby.com/pca/C.Articles/articles/year.
2002/philsbio.htm
Kaoru Ishikawa é mais conhecido por seu livro Guide to Quality Control. Ele desen-
volveu o conceito dos círculos de qualidade e foi um dos pioneiros na utilização do
diagrama de espinha de peixe, em inglês, fishbone.
Círculos de Qualidade são grupos de não-supervisores e líderes de trabalho num de-
partamento da organização que são voluntários na condução de grupos de estudos para
melhoria da qualidade e da produtividade do trabalho em seus departamentos.
Ishikawa sugeriu que gerentes e trabalhadores japoneses eram totalmente com-
prometidos com a qualidade, mas que a maioria das organizações dos Estados Unidos
delegava responsabilidades de qualidade para algumas pessoas.
O diagrama de espinha de peixe, algumas vezes chamado diagrama de Ishikawa, tra-
ça as reclamações sobre os problemas de qualidade de volta para as responsabilidades
das operações de produção. Em outras palavras, tais diagramas ajudam a identificar a
rota da causa dos problemas de qualidade. A Figura 3.1 ilustra um exemplo de dia-
grama de espinha de peixe.
Usuários não
Treinamento renovaram a senha Sistema de
Hardware
Usuários não
configuraram para
salvar as senhas Problema:
Usuários não
podem logar
Memória no sistema
Versão
Insuficiente
desatualizada
Sem espaço
no HD Processador
lento
Software Hardware do
usuário
F I G U R A 3 . 1 Exemplo de Diagrama de espinha de peixe

Genichi Taguchi é conhecido por ter desenvolvido os métodos Taguchi para otimi-
zação de processos de engenharia de experimentação. Em 1998, a revista Fortune pu-
blicou um artigo intitulado “Japan’s Taguchi is America’s new hero” (ou seja, “Tagu-
chi do Japão é o novo herói da América”). Muitas organizações, incluindo a Xerox, a
Ford, a Hewlett-Packard e a Goodyear, já utilizaram o Design Robusto de Taguchi para
desenvolver produtos de alta qualidade.
Referências bibliográficas e links na Internet sobre Kaoru Ishikawa

Yoshio Kondo. “Kaoru Ishikawa: What He Thought and Achieved, A Basis for Further Research”.
Quality Management Journal, julho de 1994, pp. 86-91.
Greg Watson. The Legacy of Ishikawa. Quality Progress, abril de 2004, pp. 54-7.
Donald L Dewar. “A Serious Anomaly: TQC without Quality Circles”. In: Annual Quality Con-
gress, Dallas, TX, May 1988, v. 42. n. 0, pp. 34-8.
Site
Quality Gurus – Kaoru Ishikawa
http://qualitygurus.com/gurus/list-of-gurus/kaoru-ishikawa/
Armand V. Feigenbaum desenvolveu o conceito de controle de qualidade total

(TQC) em 1983 no seu livro Total Quality Control: Engineering and Management. No
TQC a qualidade do produto é mais importante do que as taxas de produção; e é per-
mitido aos trabalhadores parar a produção quando ocorrem problemas de qualidade.
Esses especialistas ajudaram a definir o cenário do moderno gerenciamento da
qualidade. Hoje em dia, muitas pessoas estão familiarizadas com o Prêmio Malcolm
Baldrige – iniciado em 1987 – para reconhecer as organizações que têm alcançado um
nível mundial de competição através do gerenciamento de qualidade.
Referências bibliográficas e links na Internet sobre Armand V. Feigenbaum

Livros
Feigenbaum, A. V. Quality Control: Principles, Practice, and Administration. Nova York: McGraw-Hill,
1951.
Feigenbaum, A. V. Total Quality Control., Nova York: McGraw-Hill Professional, 2004.
Sites
Quality Gurus – Armand V. Feigenbaum
http://qualitygurus.com/gurus/list-of-gurus/armand-feigenbaum/
General Systems Company
http://www.feigenbaum.com/

CAPÍTULO 3 85
Outros métodos que ajudam a melhorar a qualidade dos projetos

Existem outros métodos que ajudam a melhorar a qualidade dos projetos, sejam de
tecnologia da informação ou de outras naturezas, tais como liderança, entendimento
do custo da qualidade, oferecimento de um local agradável de trabalho e adoção de
modelos de maturidade.
O comprometimento da alta gerência

Uma das maiores causas de problemas de qualidade é a falta de uma liderança. À me-
dida que a globalização aumenta e os clientes vão ficando cada vez mais exigentes (e
com razão), criar produtos e serviços de qualidade com preços atrativos é a essência
para sobreviver no mundo dos negócios.
Ter um bom sistema de qualidade ajuda as empresas a serem competitivas. Para
estabelecer e implementar efetivos sistemas de qualidades, a alta gerência deve se
comprometer ao máximo e estabelecer diretrizes.
Um grande percentual de problemas de qualidade está associado a problemas de
gerenciamento, e um percentual menor a aspectos técnicos. Por isso, a alta gerência
e os executivos seniores devem assumir as responsabilidades de criar, apoiar e pro-
mover sistemas de qualidade, além de declarar explicitamente na filosofia da organi-
zação o comprometimento com a qualidade, implementar treinamentos de princí-
pios e conceitos de qualidade em toda a organização, implementar métricas para es-
tabelecer e monitorar níveis de qualidade e sempre enfatizar e demonstrar a impor-
tância da qualidade.
Quando todos os funcionários entendem e insistem em criar produtos e serviços de
alta qualidade, significa que a alta gerência fez um bom trabalho de conscientização.
O custo da qualidade
O custo da qualidade é o custo da conformidade mais o custo da não-conformidade.
Conformidade significa produtos entregues conforme solicitado. Exemplos associa-
dos a custos de conformidade são desenvolvimento de planos de qualidade, custos de
análise e gerenciamento de requisitos do produto e custos de testes. O custo de
não-conformidade significa assumir responsabilidade por falhas ou expectativas de
qualidade não alcançadas.
Os custos da qualidade podem ser divididos em cinco categorias:
Custo de prevenção. O custo de planejar e executar um projeto livre de erros ou

dentro de uma margem aceitável de erros. Ações preventivas como treinamen-
tos, estudos detalhados relacionados à qualidade, pesquisas de qualidade dos
fornecedores e empresas subcontratadas estão presentes nesta categoria.
Custo de avaliação. O custo de avaliar o processo e suas saídas para assegurar que
um projeto está livre de erros ou dentro de uma margem aceitável de erros.
Atividades como inspeção e teste de produtos, manutenção e inspeção de equi-

pamentos de teste, processamento e documentação dos dados de inspeção con-

tribuem para os custos de avaliação da qualidade.
Custo de falha interna. O custo para corrigir um defeito detectado antes de o
cliente receber o produto. Esse tipo de custo ocorre com freqüência em proje-
tos de desenvolvimento de software. Quanto custa para a empresa executora
consertar os bugs? É importante que o gerente de projetos esteja atento a esse
tipo de custo.
Custo de falha externa. O custo relacionado a todos os erros não detectados e cor-
rigidos antes de entregar o produto ao cliente.
Custos de equipamentos de medidas e testes. O custo capital de equipamentos utiliza-
dos para realizar atividades de avaliação e prevenção.
Muitas indústrias toleram um pequeno custo da não-conformidade, mas essa tolerân-

cia é menos aceitável na indústria de tecnologia da informação. Os executivos seniores
são os responsáveis diretos pelos altos custos da não-conformidade. Esses executivos
devem criar uma cultura corporativa que abrace a qualidade, fomentando sua impor-
tância e conduzindo os projetos de tecnologia da informação através dessas diretrizes.
Aspectos ambientais
Outro aspecto relevante sobre a melhoria da qualidade em projetos é propiciar um
local de trabalho agradável aos recursos humanos. Esse é um fator-chave que reflete
diretamente na produtividade dos funcionários, principalmente para equipes de de-
senvolvimento de software, que precisam de um lugar sossegado para suas análises,
documentações, codificações e testes.
Quantas vezes você já ouviu um funcionário dizer: “Esse é um lugar gostoso de se
trabalhar!”? Os executivos devem se preocupar também com esses aspectos ambientais
para melhorar a produtividade e o prazer dos funcionários nesse ambiente; conseqüen-
temente, a qualidade dos produtos entregues e dos serviços oferecidos aumentará.
Modelos de maturidade
Outra forma de abordar a qualidade de projetos é através da adoção de modelos de
maturidade. Esses modelos ajudam as organizações na melhoria dos seus processos e
sistemas.
Nas próximas seções, apresentaremos alguns dos modelos mais amplamente utili-
zados em projetos de tecnologia da informação, com certa ênfase em projetos de de-
senvolvimento de software. Os modelos aqui abordados serão: SQFD, CMM,
ABNT e OPM3.
SQFD – Software Quality Function Deployment

Durante a década de 1990, a melhoria da qualidade e a redução de custos foram os
principais desafios para a produção de software. Para assegurar um alto grau de confor-

CAPÍTULO 3 87
midade do produto com os requisitos dos usuários, várias empresas utilizaram o Des-
dobramento da Função Qualidade do Software (SQFD – Software Quality Function
Deployment), uma adaptação do método QFD (Quality Function Deployment).
O modelo SQFD é uma adaptação do método QFD, originário do Japão, para o
desenvolvimento de software. O SQFD enfatiza que a Garantia da Qualidade de
Software (SQA – Software Quality Assurance) inicia-se a partir da fase de especificação
de requisitos, na qual são coletadas e muito bem documentadas as necessidades dos
usuários e, por fim, traduzidas em características técnicas e funcionalidades do pro-
duto.
Essa abordagem está relacionada ao desenvolvimento de software centrado no
usuário, em que a participação deste é um fator imprescindível para se determinar a
usabilidade e a aderência do produto, além de outros aspectos de qualidade.
Capability Maturity Model – CMM

Amplamente difundido, o CMM (Capability Maturity Model) é outro modelo de ma-
turidade, que foi desenvolvido pelo SEI (Software Engineering Institute) na Universida-
de de Carnegie Mallon e está em constante evolução.
O CMM é um modelo baseado em cinco níveis e ajuda na melhoria dos processos
de desenvolvimento de software.
F I G U R A 3 . 2 Os Cinco Níveis do Modelo de Maturidade CMM
A seguir apresentamos uma descrição sucinta dos cinco níveis.
Initial. O processo de software é caracterizado como ad oc, e ocasionalmente

caótico. Poucos processos são definidos, e o sucesso dos projetos depende dos
esforços individuais.

Repeatable. Processos básicos de gerenciamento de projetos são estabelecidos

para monitorar custos, cronograma e funcionalidades. Deve haver uma disci-
plina de processos para repetir o sucesso em projetos similares.
Defined. O processo de software para atividades de gerenciamento e engenharia
é documentado, padronizado e integrado num padrão de processo de software
para a organização. Todos os projetos da organização seguem e utilizam esse pa-
drão para o desenvolvimento e manutenção de software.
Managed. Métricas detalhadas de processos de software e qualidade de produto
são coletadas. Os processos de software e de produtos são quantitativamente
compreendidos e controlados.
Optimizing. A contínua melhoria de processos é possível através de feedback
quantitativo dos processos, de idéias inovativas e de tecnologias.
Exceto o nível 1 (Initial), todos os outros níveis são decompostos por proces-
sos-chave que indicam quais áreas na organização devem focar na melhoria dos pro-
cessos de desenvolvimento de software.
Mais informações sobre o CMM podem ser acessadas no URL:
http://www. sei.cmu.edu/cmm/.
Pesquisas de Modelo de Maturidade de William Ibbs e Young H. Kwak

William Ibbs e Young H. Kwak também pesquisam sobre maturidade de gerencia-
mento de projetos. Em seus estudos, eles desenvolveram uma metodologia de ava-
liação de medida da maturidade de gerenciamento de projetos, que consiste em um
questionário com 148 questões de múltipla escolha no qual cada resposta tem seu de-
terminado peso.
A metodologia desses dois professores é considerada uma das maiores contribui-
ções para o estudo de maturidade em gerenciamento de projetos.
Muitas organizações estão avaliando onde se enquadram em termos de maturida-
de de gerenciamento de projetos. Além disso, a metodologia já vem sendo ampla-
mente realizada em relação à maturidade de desenvolvimento de software.
As empresas estão reconhecendo que devem se comprometer com a disciplina de
gerenciamento de projetos para melhorar a qualidade dos projetos e sobreviver nes-
se mercado altamente competitivo e globalizado.
17 Pontos para Maturidade de Gerenciamento de Projetos

Kerzner descreve 17 pontos que devem ser considerados para maturidade de geren-
ciamento de projetos:
1. Adotar uma metodologia de gerenciamento de projetos e utilizá-la de forma
consistente.
2. Implementar uma filosofia que guiará a empresa na direção da maturidade
de gerenciamento de projetos e comunicá-la a todos.

CAPÍTULO 3 89
3. Empenhar-se no desenvolvimento de planos eficazes no começo de cada

projeto.
4. Determinar os objetivos utilizando o critério SMART.
5. Minimizar as mudanças de escopo através da determinação de objetivos rea-
lísticos.
6. Reconhecer que gestão de custo e de cronograma são inseparáveis.
7. Selecionar a pessoa certa para ser o gerente do projeto.
8. Estabelecer as expectativas com os executivos no início do projeto.
9. Entender as prioridades dos gerentes funcionais.
10. Preparar e comunicar os critérios de aceitação.
11. Obter suporte do patrocinador e executivo do projeto, estabelecer objeti-
vos claros, desenvolver um plano de comunicação.
12. Compartilhar o reconhecimento do sucesso do projeto com o time inteiro
do projeto e os gerentes funcionais.
13. Eliminar reuniões não produtivas.
14. Focar na identificação e resolução de problemas o mais breve possível, de
forma rápida e com o menor custo.
15. Mensurar o progresso periodicamente.
16. Usar software de gerenciamento de projetos como uma ferramenta – não
como um substituto de planejamento efetivo ou habilidades interpessoais.
17. Instituir um programa de treinamento para todos os empregados com atua-
lizações periódicas baseadas em lições aprendidas e documentadas.
OPM3 – Organizational Project Management Maturity Model do PMI

Um pouco de história
Em maio de 1998, membros do PMI Standard Committee iniciaram um projeto para
criar um padrão que descreveria como as empresas deveriam gerenciar seus projetos
para se tornarem mais eficientes.
Marge Combe e Paul Dinsmore foram indicados para serem os subgerentes do
projeto. A equipe do projeto tinha dois objetivos iniciais: 1) refinar o critério que di-
ferencia organização madura de organização não-madura e 2) examinar os aspectos
dos modelos de maturidade existentes.
O objetivo desse trabalho era identificar as áreas de alto nível que um modelo de-
veria conduzir e aprender mais sobre os processos de modelagem de maturidade.
Nesse ínterim, John Schlichter foi indicado para ser o gerente e coordenar as ativi-
dades do projeto para o Simpósio e Seminário do PMI em 1998, onde a equipe inicial
do projeto foi apresentada.
Em 1999 o Comitê foi reestruturado e criado o SMAG, Standard Member Advi-
sory Group. A visão de padronização seria promover no gerenciamento de projetos
o interesse de criar projetos que resultassem no sucesso da organização, enfatizando

o gerenciamento de projeto organizacional como uma ferramenta de estratégia.

Schlichter replanejou o esforço em um programa de cinco projetos, recrutou 100
voluntários e nomeou gerentes de projetos e líderes de projetos para a empreitada.
Atualmente o OPM3 (Organizational Project Management Maturity Model)
consiste de membros de todo o mundo que contribuem com conhecimentos, habili-
dades e experiência para o programa. Os patrocinadores são a Diretoria do PMI
(PMI Board), o Gerente dos Padrões Técnicos Steve Fahrenkrog e o PMI Standard
Member Advisory Group.
Os clientes desse projeto incluem profissionais de gerenciamento de projetos,
executivos e gerentes seniores. As organizações são o alvo do modelo de maturidade
de gerenciamento de projeto. Os executivos e executivos seniores são as pessoas nas
organizações que patrocinarão a implementação de tais modelos pelos profissionais
de gerenciamento de projetos.
O objetivo desse programa é desenvolver um padrão universal de maturidade de
gerenciamento de projetos que beneficiará a todos.
Visão geral do programa
O que significa Organizational Project Management Maturity Model? Primeiro, o
termo Organizational amplia o domínio de gerenciamento de projetos para além do
projeto, que é assunto do PMBOK.
O uso da palavra Maturity (maturidade) implica que habilidades (competência,
capacidades) devem evoluir com o tempo para produzir sucessos repetitivos em ge-
renciamento de projetos e, conseqüentemente, nos projetos.
Quando realizamos múltiplos projetos, visualizamos e entendemos o gerencia-
mento de projetos como um sistema holístico que se estende por toda a empresa.
Os projetos se interagem e mudam numa teia de prioridades dinâmicas. Eles reali-
zam o trabalho que representa os anseios estratégicos da empresa.
Nesse contexto, o gerenciamento de projetos é mais do que uma implementação. Está
estreitamente aderente e alinhado com as prioridades estratégicas da empresa, promoven-
do um ambiente e uma infra-estrutura adequados para o gerenciamento dos projetos.
Existe um aumento do interesse de empresas orientadas a projetos em aprender
sobre e como desenvolver um modelo de maturidade que mostre passo a passo um
método de melhorar e manter a habilidade da empresa em traduzir a estratégia orga-
nizacional na realização de projetos consistentes e de sucesso.
Como vimos, já existem alguns modelos de maturidade. Modelos para organiza-
ções que querem aumentar suas habilidades para desenvolver e gerenciar software,
sistemas de engenharia, sistemas de seguranças, sistemas de aquisição, recursos hu-
manos, entre outros.
Sobre o OPM3
Assim como os indivíduos se beneficiam quando alcançam a maturidade, as organizações
podem se beneficiar de maturidade organizacional em gerenciamento de projetos.

CAPÍTULO 3 91
OPM3 (Organizational Project Managemet Maturity Model), Maturidade Orga-

nizacional em Gerenciamento de Projetos, é um padrão diferente de todos os mode-
los contemporâneos de maturidade. Este novo padrão do PMI ajuda as organizações
a avaliarem e a desenvolverem suas habilidades de obterem sucesso nos projetos de
forma consistente e previsível, além de ajudar as organizações no alinhamento de
seus objetivos estratégicos.
Este padrão está baseado em três elementos: knowledge, assessment e improvement.
O elemento knowledge permite as organizações a descobrirem centenas de melho-
res práticas e demonstra como implementá-las.
O elemento assessment é uma ferramenta interativa que permite as organizações
avaliarem a situação atual de gerenciamento de projetos e identificarem aquelas áreas
que necessitam de melhorias.
Se as organizações decidem investir no nível mais alto de maturidade, o elemento
improvement irá ajudá-las a mapear os passos necessários para alcançar os objetivos.
Maiores informações sobre o OPM3 podem ser acessadas nos sites www.pmi.org e
www.pmibookstore.org
A segunda edição do OPM3 está prevista para o final de 2008. Você pode ser um
dos voluntários e experimentar a participação em um projeto envolvendo diversos
países e centenas de pessoas de várias culturas. Eu fui voluntário no desenvolvimento
da primeira edição do OPM3 e participarei novamente como voluntário da segunda
edição. Vale a pena participar! Maiores informações acesse: http://www.pmi.org/info/PP_
StandardsVolunteering.asp e clique em “Project Descriptions for Volunteers”, logo em se-
guida clique em “OPM3 2008 Update Project Team”. A seguir, a lista completa dos pro-
jetos do PMI nos quais você poderá se envolver como voluntário:
Component Mentor Program Member Advisory Group

OPM3 2008 Update Project Team
PMI Component Mentor Volunteer
Practice Standard for Project Risk Management
Professional Awards Program Member Advisory Group
Project Manager Competency Development Framework
Unified Project Management Lexicon Project
Escritório de projetos
O escritório de projetos é um centro de informações e controle dos padrões organi-
zacionais para gerenciamento de projetos, melhoria de processos, gerenciamento de
projetos estratégicos, capacitação de pessoas e disseminação da cultura de gerencia-
mento de projetos em toda a empresa.
Seu principal papel é garantir o funcionamento pleno e eficiente do programa
como um todo, sem assumir a direção de um ou mais projetos, individualmente.
Os objetivos da implementação de um PMO são, mas não se limitam a:

Estabelecer padrões e normas para o gerenciamento de projetos em toda a or-

ganização.
Desenvolver técnicas e ferramentas que suportem todo o ciclo de vida dos pro-
jetos.
Capacitar as equipes de projetos em metodologia e ferramentas para que sejam
capazes de fazer o melhor uso das funcionalidades disponibilizadas pelo PMO.
Desenvolver sistemas que disponibilizem informações sobre os projetos em ní-
vel corporativo.
Promover melhoria contínua.
Garantir que projetos sejam selecionados e priorizados segundo critérios e res-
trições de negócio, considerando os recursos disponíveis e os objetivos estraté-
gicos (BSC).
Incrementar a Taxa de Sucesso e o ROI dos projetos através da melhoria conti-
nua das práticas de Gerenciamento de Projetos, apoiando-se em metodologia,
capacitação das pessoas e ferramentas.
Otimizar a alocação e utilização dos recursos de TI em projetos.
Gerenciar riscos de grande impacto para a Organização.
Prover meios para que informações sobre os projetos estejam disponíveis para a
Organização, em especial para a Alta Administração.
Normas ISO aplicadas à Tecnologia da Informação

O ISO 9000, um padrão de sistema de qualidade desenvolvido pelo International
Organization for Standardization (ISO), é um círculo contínuo de três partes: plane-
jamento, controle e documentação da qualidade em uma organização. O PMI – Project
Management Institute – anunciou em 1999 a sua certificação ISO 9000 e o PMBOK
Guide de 1996 foi reconhecido como um padrão nacional norte-americano.
O moderno gerenciamento da qualidade, os prêmios de qualidade e os padrões de
qualidade são aspectos importantes de conhecimento para os gerentes de projetos.
Enfatizar o controle da qualidade no gerenciamento de projetos garante que produ-
tos e serviços sejam produzidos (entregues) de modo a atender (e por que não supe-
rar?) às necessidades e expectativas dos clientes.
Nova Norma Brasileira para Sistemas de Gestão da Qualidade

A nova versão da norma brasileira NBR ISO 9000:2005, Sistemas de Gestão da Qua-
lidade – Fundamentos e Vocabulários, acaba de ser revisada e publicada pela ABNT –
Associação Brasileira de Normas Técnicas – e já está disponível para as empresas cer-
tificadas ou em processo de certificação de seus Sistemas de Gestão da Qualidade.
A norma é aplicável às organizações que buscam por vantagens através da imple-
mentação de um Sistema de Gestão da Qualidade, maior confiança nos seus fornece-
dores quanto aos requisitos e qualidade dos produtos e serviços prestados e que dese-
ja aplicar a terminologia adequada à área de gestão da qualidade, a fim de buscar ex-

CAPÍTULO 3 93
celência em toda gestão. Descreve os fundamentos de sistemas de gestão da qualida-

de, que constituem a série de normas NBR ISO 9000, e define os termos a ela rela-
cionados.
Novos termos e definições foram adicionados e algumas notas explicativas foram
acrescentadas. Alguns diagramas que figuram na NBR ISO 9000:2000 foram realça-
dos na versão 2005 e termos como perito técnico, exigência, competência, contra-
to, revisor de contas, equipe do exame, planta do exame e espaço do exame mos-
tram como a nova norma NBR ISO 9000:2005 traz um vocabulário mais rico, facili-
tador no entendimento de seus usuário, sendo um verdadeiro auxiliar no processo
de melhorias contínuas aplicadas.
Manter-se bem informado, atualizado e sempre competitivo junto ao mercado
em que atua, quanto à qualidade de seus produtos e serviços, é o objetivo de todo o
profissional envolvido na gestão da qualidade das organizações. A nova versão da
norma brasileira torna o processo de certificação mais fácil e efetivo, podendo assim,
garantir o sucesso da gestão da qualidade nas organizações que atuam no Brasil.
Novas Normas Internacionais para a Gestão de Serviços de Tecnologia da Informação

A ISO/IEC 20000 – Information Technology – Service Management, foi desenvol-
vida para responder a uma necessidade do mercado mundial e também fornecer um
entendimento comum, no que diz respeito à Gestão de Serviços de Tecnologias de
Informação, a todas as organizações envolvidas neste setor. Ela substitui a renomada
norma britânica BS 15000 e, semelhantemente, se divide em duas partes, facilitando
assim a sua aplicação e também o entendimento de todos os envolvidos, sejam clien-
tes internos ou externos.
As duas partes que compõem a nova norma são as seguintes:
PARTE 1: ISO/IEC 20000-1:2005 – Information Technology – Service Management

– Part 1: Specification – Fornece os requisitos de gestão de serviços e é relevante aos
responsáveis pela preparação, implementação ou gestão continuada dos serviços de
TI nas organizações. As organizações poderão assegurar a certificação dos seus siste-
mas de gestão de serviços de TI de modo independente, em conformidade com os re-
quisitos da ISO/IEC 20000-1:2005.
PARTE 2: ISO/IEC 20000-2:2005 – Information Technology – Service Management

– Part 2: Code of practice – Fornece orientações aos auditores internos das organiza-
ções e assistência aos prestadores de serviços, que planejam melhorias no serviço
prestado ou desejam preparar o ambiente para auditorias em relação à norma
ISO/IEC 20000-1:2005, buscando a certificação.
Com a aplicação da nova norma, o setor de tecnologia da informação, que está
sempre em busca de inovações, melhores resultados na prestação de seus serviços e
preocupado em garantir a satisfação de todos os seus clientes, passará a ter maior

controle de seus processos e irá torná-los cada vez mais eficazes e alinhados, de acor-
do com os novos requisitos, garantindo assim o sucesso de suas negociações, em um
mercado cada vez mais competitivo e globalizado.
Norma para Segurança da Informação

A norma técnica brasileira NBR ISO/IEC 27001:2006 – Tecnologia da Informação
– Técnica de Segurança – Sistema de Gestão de Segurança da Informação – Estabele-
ce requisitos e diretrizes que lhe ajudarão a implantar, analisar criticamente e moni-
torar, gerenciar e manter um Sistema de Gestão da Segurança da Informação com-
pleto e eficaz.
Será através da NBR ISO/IEC 27001 que o setor de Segurança da Informação au-
mentará a sua competitividade junto ao mercado global e muitas empresas, que antes
utilizavam os requisitos da norma estrangeira BS 7799 – Parte 2 para certificarem os
seus SGSIs, passarão a implementar o novo modelo de Segurança da Informação Tec-
nológica. A norma técnica também complementa a NBRISO/IEC 17799, também
publicada recentemente, e é conhecida como o “Código de Práticas” para o setor de
Gestão de Segurança da Informação, em todo o mundo.
Normas ISO de Tecnologia da Informação (Software e Hardware)

Além da norma ISO 9000:2005, existem normas específicas para área de TI. Abaixo
listo as normas técnicas de TI disponíveis em português no Brasil.
ABNT ISO/IEC TR14471 Tecnologia da informação – Engenharia de software

– Orientação para adoção de ferramentas CASE.
NBR10346 PB1322 Tecnologia de informação – Teclados em equipamentos
de processamento de dados – Conjunto alfanumérico.
NBR10347 PB1323 Tecnologia de informação – Teclados em equipamentos
de processamento de dados – Conjunto numérico.
NBR11418 MB3276 Tecnologia de informação – Fitas magnéticas de 12,7mm
com densidade de gravação de até 246bit/mm – Verificação dos requisitos físi-
cos e magnéticos.
NBR11423 PB1507 Tecnologia de informação – Computação gráfica – Núcleo
básico GKS – Descrição funcional.
NBR11424 PB1508 Tecnologia de informação – Computação gráfica – Núcleo
gráfico GKS – Interface para linguagem FORTRAN.
NBR12473 PB1535 Tecnologia de informações – Redes locais – Uso do proto-
colo X.25 nível pacote.
NBR12475 PB1537 Tecnologia de informação – Interconexão de sistemas
abertos – Serviços da camada de rede.
NBR12476 PB1538 Sistema de processamento de informação – Interconexão
de sistemas abertos – Serviços da camada física.

CAPÍTULO 3 95
NBR12896 Tecnologia de informação – Gerência de senhas.

NBR12940 Tecnologia de informação – Cabos para utilização em redes locais –
Medição de impedância de transferência em cabos coaxiais.
Medição de jitter de face em cabos coaxiais e em cabos de pares.
Medição de diafonia em cabos de pares.
NBR12943 Tecnologia de informação – Interconexão de sistemas abertos –
Definição do serviço de sessão orientado à conexão.
NBR12963 Tecnologia da informação – Intercâmbio eletrônico de dados para
administração, comércio e transporte (EDIFACT) – Regras de sintaxe relacio-
nadas à aplicação.
NBR12964 Tecnologia de informação – Técnicas criptográficas de dados –
Modos de operação de um algoritmo de cifração de blocos padrão.
NBR12965 Tecnologia de informação – Sistemas de processamento de infor-
mação – Redes locais – Controle de enlace lógico.
Endereçamento da camada de rede.
Camada de enlace – Estrutura do quadro nos procedimentos HDLC.
Definição do serviço de apresentação orientado à conexão.
Protocolo de transporte orientado à conexão.
Protocolo de transporte no modo sem conexão.
Serviço para elemento de serviço de controle de associação (ACSE).
Protocolo de transporte orientado à conexão – Adendo 1: Subprotocolo de ge-
renciamento de conexão de rede.
NBR9611 PB1201 Tecnologia de informação – Código brasileiro para inter-
câmbio de informação.
NBR9614 MB2580 Código brasileiro para intercâmbio de informações – Veri-
ficação dos caracteres gráficos.
NBR9943 EB1773 Técnicas de extensão de código para uso com o código bra-
sileiro para intercâmbio de informação.
NBRISO/IEC12119 Tecnologia de informação – Pacotes de software – Teste
e requisitos de qualidade.
NBRISO/IEC12207 Tecnologia de informação – Processos de ciclo de vida de
software.

NBRISO/IEC14102 Tecnologia de informação – Orientação para avaliação e

seleção de ferramentas CASE.
NBRISO/IEC14143-1 Tecnologia de informação – Medição de software –
Medição de tamanho funcional – Parte 1: Definição de conceitos.
NBRISO/IEC14598-1 Tecnologia de informação – Avaliação de produto de
software – Parte 1: Visão geral.
NBRISO/IEC14598-2 Engenharia de software – Avaliação de produto – Parte
2: Planejamento e gestão.
3: Processo para desenvolvedores.
4: Processo para adquirentes.
NBRISO/IEC14598-5 Tecnologia de informação – Avaliação de produto de
software – Parte 5: Processo para avaliadores.
6: Documentação de módulos de avaliação.
NBRISO/IEC17799 Tecnologia da informação – Técnicas de segurança – Có-
digo de prática para a gestão da segurança da informação.
NBRISO/IEC27001 Tecnologia da informação – Técnicas de segurança – Sis-
temas de gestão de segurança da informação – Requisitos.
NBRISO/IEC9075 Tecnologia de informação – Linguagens de banco de dados
– SQL.
NBRISO/IEC9126-1 Engenharia de software – Qualidade de produto – Parte
1: Modelo de qualidade.
ABNT – Subcomitê de Software – SC-21:10

O Subcomitê de Software (SC-21:10) é um organismo vinculado ao Comitê Brasile-
iro de Informática (CB-21) da Associação Brasileira de Normas Técnicas – ABNT,
apoiado por entidades e organizações públicas e privadas do Paraná, como também
dos demais estados brasileiros.
Sua instalação é decorrente de um convênio formalizado em junho de 1992 pelas
empresas:
ABNT – Associação Brasileira de Normas Técnicas

CELEPAR – Companhia de Informática do Paraná
POLO de Software de Curitiba
TECPAR – Instituto de Tecnologia do Paraná
Objetivos
Normalização de Software no Brasil
Produção de normas nacionais (NBR)

CAPÍTULO 3 97
Contribuição para a elaboração de normas internacionais

Representação do país nos fóruns de normalização internacionais
Aumentar o número de pessoas dedicadas às Comissões de Estudos
Responsabilidades
Responde pelas normas de Engenharia, Qualidade e Portabilidade de Software,
como as de implementações padronizadas relativas a linguagens, sistemas operacio-
nais, banco de dados e ambientes e aplicações.
Internacionalmente, é responsável pela coordenação da participação brasileira
junto ao ISO/IEC/JTC1/SC7 Software Engineering e ao ISO/IEC/JTC1/SC32
Data Management and Interchange da ISO/IEC/JTC1.
Os Comitês Brasileiros (CB) e os Organismos de Normalização Setorial (ONS)
mantêm Comissões de Estudos (CE) em atividades nas mais diversas áreas. Seus inte-
grantes trabalham voluntariamente e, através de consenso, analisam e debatem pro-
postas de projetos de norma, que são submetidos à votação nacional para passarem à
condição de Norma Brasileira (NBR). A participação é aberta a toda a comunidade,
bastando entrar em contato com o presidente da CE ou com a Secretaria Executiva.
Localização
O Subcomitê é hospedado pela CELEPAR – Companhia de Informática do Paraná
Rua Mateus Leme, 1142 – 5o andar
80530-010 – Curitiba – Paraná – Brasil
Telefone: (41) 350-5347
Fax: (41) 352-2222
E-mail: abnt_sw@pr.gov.br
Mantenedores
ABNT – Associação Brasileira de Normas Técnicas
CELEPAR – Companhia de Informática do Paraná
POLO de Software de Curitiba
TECPAR – Instituto de Tecnologia do Paraná
ASSESPRO – Associação das Empresas Brasileiras de Software e Serviços de
Informática
CITS – Centro Internacional de Tecnologia em Software
Estrutura do SC-21:10
Coordenador Nacional: Dr. Kival Chaves Weber
Coordenador Executivo: Danilo Scalet
Coordenador Adjunto: Milton Pires Ramos
Secretaria Executiva: Ivan de Barros Ravedutti e Marisa Cardoso Marques
abnt_sw@pr.gov.br

Comissões
As Comissões Técnicas – CT – são responsáveis pelas pesquisas junto à comunidade
para verificar o interesse em abrir comissões de estudos – CE. Essas CE são responsá-
veis pela elaboração das propostas de textos normativos, que, após aprovadas, dão
origem às Normas Brasileiras – NBR.
CT-21:101 – Comissão Técnica de Engenharia de Software e Portabilidade de
Software. Coordenadora – Cristina Ângela Filipak Machado. Instalada em junho de
1992.
Comissões de Estudos
CE-21:101.01 – Qualidade de Software
CE-21:101.03 – Gerência do Ciclo de Vida do Software
CE-21:101.04 – Avaliação de Processos de Software
CE-21:101.05 – Ferramenta e Ambiente (sendo atualizada)
CE-21:101.06 – Estimativa de Tamanho de Software (Ponto por Função)
CE-21:101.08 – Ergonomia de Software
CT-21:102 – Comissão Técnica de Linguagens, Sistemas Operacionais e Ban-
cos de Dados. Coordenador – Vanderlei Vilhanova Ortêncio. Instalada em ju-
nho de 1992
Comissões de Estudos
CE-21:102.01 – Linguagem SQL
CE-21:102.09 – SQL Multimídia
CE-21:102.10 – Metadados
Normas Técnicas Brasileiras (NBR)

A Norma se faz presente na fabricação de produtos e na transferência de tecnologia,
através de informações codificadas.
É aplicável na melhoria da qualidade de vida através, por exemplo, de normas re-
lativas à saúde, segurança e preservação do meio ambiente.
Sua necessidade decorre da manifestação da sociedade sobre determinado assun-
to. O trabalho é feito pelas Comissões de Estudos que elaboram o projeto, o qual é
submetido à Votação Nacional pelos associados da ABNT e demais interessados.
As sugestões são analisadas e aprovadas pelo Conselho Técnico da ABNT, surgin-
do, então, a Norma Brasileira (NBR).
Normas Publicadas
NBR 13596/96 – Tecnologia de Informação – Avaliação de Produto de Soft-
ware – Características de Qualidade e Diretrizes para o seu uso.
NBR ISO/IEC 12119/97 – Pacotes de Software – Testes e Requisitos de Qua-
lidade.

CAPÍTULO 3 99
NBR ISO/IEC 12207/97 – Tecnologia da Informação – Processos do Ciclo de

Vida de Software.
NBR ISO/IEC 9075/97 – Tecnologia da Informação – Linguagem de Banco de
Dados – SQL.
Normas com votação nacional concluída aguardando publicação pela ABNT

NBR ISO/IEC 14598-1-99 – Tecnologia de Informação – Avaliação de produ-
tos de software – Parte 1 – Visão Geral.
ISO/IEC 14102:95-2000 – Information Technology – Guideline For The Eva-
luation and Selection of CASE Tools.
NBR ISO IEC 14598-5-2000 – Tecnologia de informação – Avaliação de pro-
duto de Software – Parte 5: Processo para avaliadores.
Normas encaminhadas para consulta pública pela ABNT

NBR ISO IEC 14471:99 – Information Technology – Guideline For The Adop-
tion of CASE Tools.
NBR ISO/IEC 14598-3-2001 – Tecnologia de Informação – Avaliação de pro-
dutos de software Parte 3 – Processo para desenvolvedores.
NBR ISO IEC 14143-1-2000 – Tecnologia de Informação – Medição de soft-
ware – Medição de tamanho funcional – Parte 1: Definição de conceitos.
Normas encaminhadas para votação pelas comissões de estudos

NBR ISO IEC 9241-1 – Requisitos Ergonômicos para Trabalho de Escritórios
com Computadores Parte 1 – Introdução Geral.
NBR ISO IEC 9241-3 – Requisitos Ergonômicos para Trabalho de Escritórios
com Computadores Parte 10 – Orientações sobre Usabilidade.
NBR ISO IEC 15026 – Níveis de integridade de software e sistemas.
NBR ISO IEC RT 15271 – Guia para a 12207.
Normas em estudo pelas CE

CE-21:101.01 – ISO IEC 14598-2, 14598-4, 14598-6 – / ISO IEC 9126-1,
9126-2. 9126-3 e 9126-4.
CE-21:101.03 – ISO IEC 16326 / NBR ISO IEC 15026 / ISO IEC 14764 /
ISO IEC 15288 /.
NBR ISO IEC 15271 / NBR ISO IEC RT 15846.
CE-21:101.04 – ISO IEC 15504.
CE-21:101.05 – WD 15940, WD 18018.
CE-21:101.06 – ISO IEC 14143-2 / 14143-3 / 14143-4 / 14143-5.
CE-21:101.08 – ISO IEC 9241-10.
CE-21:102.01 – ISO IEC 9075-1.
CE-21:102.09 – ISO IEC 13249.

A iniciativa do Comitê Brasileiro de Informática (CB-21), da Associação Brasileira

de Normas Técnicas (ABNT) e das organizações conveniadas é de extrema impor-
tância para a comunidade de tecnologia da informação do Brasil. Na prática, ela
certamente aumentará ainda mais o nível da qualidade do software brasileiro, que já
provou ser um dos melhores do mundo!
É importante que o gerente de projetos de TI e os integrantes da equipe tenham
conhecimento da existência dessas normas e principalmente tenham acesso a elas,
pois projetos de TI podem ter como premissa a consulta e a utilização das mesmas. As
normas podem ser adquiridas em formato eletrônico (inclusive em CD) no site
www.target.com.br.
GERENCIANDO PESSOAS
Psicólogos e teóricos da administração de empresas vêm desenvolvendo muitas pes-
quisas e pensamentos no campo do gerenciamento de pessoas no ambiente de traba-
lho. A seguir serão descritas sucintamente algumas dessas teorias.
Teorias da motivação
Abraham Maslow, um psicólogo altamente respeitado que rejeitou o negativismo
desumanizador da psicologia em 1950, é mais conhecido por ter desenvolvido a hie-
rarquia das necessidades.
Em 1950 proponentes da teoria de Sigmund Freud promoveram a idéia de que os
seres humanos não eram os donos de seus destinos e que todas as ações eram gover-
nadas por processos inconscientes dominados por seus desejos sexuais primitivos.
Nesse mesmo período, psicólogos do comportamento concluíam que os seres huma-
nos eram controlados pelo meio-ambiente.
Maslow argumentou que ambas as escolas de pensamento falhavam em reconhe-
cer as únicas qualidades do comportamento humano: amor, auto-estima, posse, au-
to-expressão e criatividade. Para ele, essas qualidades únicas permitem que os seres
humanos sejam capazes de fazer suas escolhas independentemente e de ter controle
total sobre seus destinos.
A estrutura da hierarquia das necessidades de Maslow mostra que o comporta-
mento das pessoas é guiado e motivado por uma seqüência de necessidades: fisio-
lógica, de satisfação, social, de estima e de auto-atualização. Na base da pirâmide
da hierarquia estão as necessidades fisiológicas. Uma vez que as necessidades de
satisfação são alcançadas, as necessidades sociais são supridas; logo em seguida, a
estima e, por último, a auto-atualização. De acordo com a teoria de Maslow, só é
possível alcançar o topo da pirâmide, ou seja, a auto-atualização, quando as ou-
tras necessidades forem supridas. A teoria das necessidades de Maslow conduz a
uma mensagem de esperança e crescimento. As pessoas podem controlar seus
destinos e naturalmente se esforçar para alcançar o mais alto nível da hierarquia
das necessidades.

CAPÍTULO 3 101
Gerentes de projetos devem conhecer alguns aspectos da vida profissional e pes-

soal dos recursos do projeto para promover incentivos motivacionais que vão de en-
contro às necessidades dos membros do time do projeto.
Em 1968, Herzberg analisou os fatores que afetavam a produtividade entre 1685
empregados. Naquela época, ele concluiu que as pessoas eram motivadas pelo reco-
nhecimento profissional, por realizações pessoais e pela perspectiva de crescimento.
Douglas McGregor foi um dos maiores pesquisadores das relações humanas para o
gerenciamento e é conhecido por desenvolver as Teorias X e Y. Assim como Mas-
low, McGregor ressalta a estima e a auto-atualização como mais importante na moti-
vação dos trabalhadores.
Em 1981, William Ouchi apresentou a Teoria Z, baseada na motivação japonesa
dos trabalhadores, que dá ênfase à confiança, à qualidade, à decisão coletiva e aos va-
lores culturais.
A maioria das pessoas que trabalham em projetos de tecnologia da informação
provavelmente terá suas necessidades fisiológicas e de satisfação alcançadas.
Para motivar os membros do time do projeto, os gerentes precisam descobrir o
que motiva cada pessoa em relação ao social, à estima, à auto-atualização ou às neces-
sidades de crescimento. Nada que uma conversa descontraída não descubra!
Influência e poder
A influência está diretamente relacionada ao poder. O poder é a habilidade de influenciar
o comportamento das pessoas. Ele tem uma conotação maior do que a influência, espe-
cialmente quando é utilizado para persuadir as pessoas a mudarem de comportamento.
Os cinco tipos de poder são:
1. Poder Coercivo. Envolve a utilização de punições, ameaças ou outras abor-
dagens negativas no sentido de forçar as pessoas a fazerem coisas que elas
não querem fazer. Uma ênfase muito grande neste tipo de poder promove o
insucesso dos projetos.
2. Poder Legítimo. As pessoas realizam as tarefas baseadas na autoridade de
outra pessoa. Gerentes de projetos podem tomar decisões sem envolver os
membros da equipe do projeto. Utilizar demasiadamente este tipo de poder
também gera falhas no projeto.
3. Poder Especialista. Utiliza o conhecimento e a expertise de uma pessoa para
convencer as pessoas a mudarem de comportamento. Se as pessoas perce-
bem que os gerentes de projetos são experts em certas situações, elas segui-
rão suas sugestões. Por exemplo, se um gerente de projetos tem experiên-
cia em trabalhar com um determinado fornecedor de um produto de tecno-
logia da informação, os membros da equipe do projeto estarão mais seguros
em seguir as orientações do gerente sobre como trabalhar com aquele for-
necedor e seu produto.

4. Poder Recompensado. Usa incentivos para induzir as pessoas a realizarem

tarefas. Recompensas podem incluir dinheiro, status, reconhecimento,
promoções ou outras formas de recompensar as pessoas para o comporta-
mento desejado. Muitas teorias sugerem que somente alguns tipos de re-
compensas – como desafios, metas e reconhecimento – realmente induzem
as pessoas a mudarem seus comportamentos.
5. Poder Referencial. Este tipo de poder é baseado no carisma individual de
uma pessoa. Quando as pessoas se baseiam em alguém com poder referen-
cial, elas sentem a satisfação de realizar as tarefas ordenadas por essa pessoa.
É importante para os gerentes de projetos entenderem quais tipos de influência e

poder eles poderão utilizar em diferentes situações. As pessoas normalmente res-
pondem melhor a um gerente de projetos que motiva os membros da equipe aos de-
safios do trabalho, fornecendo-lhes reforço positivo para fazerem um bom trabalho.
Os conceitos de influência e poder devem ser utilizados sempre a favor da equipe do
projeto.
Melhorando a eficiência
Stephen Covey expandiu o trabalho realizado por Maslow, Herzberg e outros auto-
res, e desenvolveu uma abordagem para ajudar as pessoas e as equipes a serem mais
efetivas.
Gerentes de projetos podem aplicar os sete hábitos elaborados por Covey em suas
teorias:
1. Seja proativo.
2. Comece estabelecendo metas.
3. Priorize as atividades importantes.
4. Pense em vencer ou vencer.
5. Procure entender primeiro, depois seja compreendido.
6. Sinergia.
7. Afine o instrumento.
Vamos analisar cada um dos hábitos descritos por Covey.

1. Seja proativo. Covey, assim como Maslow, acredita que as pessoas têm a ha-
bilidade de ser proativas e escolher suas reações a diferentes tipos de situa-
ções. Gerentes de projetos devem ser proativos, antecipando e se preparan-
do para enfrentar problemas e inevitáveis mudanças nos projetos. Isso vale
também para os membros da equipe dos projetos. É tarefa dos gerentes de
projetos motivar suas equipes para também serem proativas.
2. Comece estabelecendo metas. Covey sugere escrever a missão do projeto para
que as pessoas desenvolvam esse hábito. Gerentes de projetos devem ajudar

CAPÍTULO 3 103
os membros de suas equipes a não “sair dos trilhos”, ou seja, a se concentrar

em atingir as metas.
3. Priorize as atividades importantes. Para Covey, a maioria das pessoas deve gastar
mais tempo fazendo coisas que são importantes, mas não urgentes. Por exem-
plo, planejamento. Gerentes de projetos precisam gastar muito mais tempo
trabalhando em atividades importantes, tais como desenvolver o plano do
projeto, melhorar o relacionamento com os envolvidos no projeto e orientar
a equipe do projeto. Um bom planejamento evita tarefas urgentes, do tipo
“para ontem”. Realizar um bom planejamento evita tais situações.
4. Pense em vencer ou vencer. Gerentes de projetos devem utilizar o paradigma
vencer ou vencer ao tomar decisões; entretanto, especialmente em situa-
ções competitivas, eles devem utilizar o paradigma vencer ou perder.
5. Procure entender primeiro, depois seja compreendido. Audição Enfática é a audição
com a intenção de entender. É mais eficaz porque essa atividade faz com que
você esqueça seus interesses pessoais e se concentre em entender a outra
pessoa. Para realmente entender as pessoas, você deve primeiro saber ou-
vi-las. Esse hábito é crítico não somente para os gerentes de projetos, mas
também para os membros da equipe do projeto.
6. Sinergia é a associação simultânea de vários fatores que contribuem para uma
ação coordenada. Em projetos de tecnologia da informação, principalmente
em projetos de desenvolvimento de software, podemos perceber claramen-
te essa característica porque existem diversos recursos trabalhando ao mes-
mo tempo em atividades diferentes, porém de forma organizada pelo se-
qüenciamento do cronograma. Cabe ao gerente de projetos coordenar essas
ações para que a sinergia possa ser produtiva. Temos, então, que o resultado
das ações cooperativas é maior que a soma dos esforços individuais e o todo
vai se moldando de forma harmoniosa.
7. Afine o instrumento. Praticar o sétimo hábito de amolar o serrote significa ti-
rar um tempo para se renovar física, espiritual, mental e socialmente. A prá-
tica da auto-renovação ajuda as pessoas a evitar a monotonia em ambientes
de trabalho. Gerentes de projeto devem se assegurar de que eles mesmos e a
equipe do projeto tenham tempo para fazer reciclagem profissional e “recar-
regar as baterias”.
Coaching
Para Idalberto Chiavenato, o conceito de coaching “está ligado ao desenvolvimento
contínuo de pessoas através de um tutor – coacher ou mestre, que é o responsável pelo
desenvolvimento de talentos e pela criação de uma nova geração de profissionais”.
Coaching tem muito a ver com gerência de projetos. Os gerentes de projetos po-
dem e devem agir como coachers dos seus recursos humanos. Para aprofundar-se no
assunto, recomendo a leitura dos seguintes livros da Campus/Elsevier Editora:

Construção de talentos: coaching & mentoring, de Idalberto Chiavenato.

Coaching: o apoio que faz as pessoas brilharem – orientação e treinamento em qualquer
situação, de Germaine Porché e Jed Niederer.
Liderando para o alto: como conduzir seu chefe em benefício de ambos, de Michael Useem.
PRINCÍPIOS BÁSICOS DE GERENCIAMENTO DE CUSTOS

Além do conhecimento técnico, gerentes de projetos de tecnologia da informação
devem estar familiarizados com os termos e conceitos do mundo das finanças.
A alta gerência das empresas e os clientes têm muito interesse nos aspectos finan-
ceiros do projeto.
Conhecer alguns conceitos e princípios básicos de gerenciamento de custos ajuda
os gerentes de projeto a apresentarem e a discutirem melhor os benefícios dos proje-
tos em termos financeiros e técnicos.
Lucro. Lucro é receita menos despesas. Para melhorar os lucros, a empresa pode re-
duzir as despesas ou aumentar as receitas, ou uma combinação de ambos. Quando
for justificar investimentos num novo projeto é importante focar no impacto dos lu-
cros, e não nas despesas.
Margem de lucro. Para medir os benefícios de um projeto é importante conhecer a

margem de lucro. Por exemplo, se uma receita de três milhões de reais gera um lu-
cro de trezentos mil, então a margem de lucro é de 10%.
Ciclo de vida do custo do projeto. Permite que você tenha uma visão geral do custo de um
projeto em toda sua extensão temporal. Isso ajuda a desenvolver uma projeção mais
apurada dos benefícios financeiros do projeto. O ciclo de vida do custo do projeto
considera aspectos tais como custo total de propriedade (TCO) e custos de suporte
para um projeto. Por exemplo, uma organização pode levar seis meses para desen-
volver um novo sistema de gerenciamento de clientes (CRM), mas esse novo sistema
poderia ser utilizado pelo cliente pelo menos durante aproximadamente três anos
sem muitas manutenções. Dependendo do contrato, essas manutenções podem es-
tar explícitas, ou em outras situações podem ser negociadas à parte com o cliente a
um menor custo do que o valor pago para todo o sistema. Em projetos de tecnologia
da informação que envolvem desenvolvimento de software, manutenções desse tipo
são comuns, já que no decorrer dos anos de utilização dos sistemas os próprios usuá-
rios podem solicitar algumas alterações e melhorias. Gerentes de projetos devem
criar estimativas de custos, avaliar os benefícios e criar um projeto sempre levando
em conta todo o seu ciclo de vida.
Análise de fluxo de caixa. É um método para determinar as estimativas de custos anuais

e benefícios para um projeto e o fluxo de caixa resultante. Isso deve ser feito para de-

CAPÍTULO 3 105
terminar o valor líquido do projeto. Gerentes devem levar em conta o fluxo de caixa
para selecionar em quais projetos investir. Se os gerentes de projeto selecionam mui-
tos projetos com necessidades de altos fluxos de caixa no decorrer do mesmo ano, a
empresa não será capaz de suportar todos os projetos e manter suas lucratividades.
Taxa interna de retorno. É uma taxa de desconto que faz o valor líquido do projeto ser
igual a zero.
Custos tangíveis. São custos facilmente mensuráveis em termos monetários.
Custos intangíveis. São custos dificilmente mensuráveis em termos monetários. Por

exemplo, horas gastas para estudar, pesquisar e elaborar propostas técnicas para so-
luções muito customizadas. Geralmente esses custos são difíceis de se justificar, mas
devem ser pelo menos comentados com o cliente para a devida valorização da equipe
do projeto e do comprometimento que a empresa teve para realizar tais atividades.
Custos diretos. São os custos associados diretamente aos recursos do projeto em ter-
mos de pessoas, material, software, equipamentos etc. Por exemplo, o salário men-
sal pago aos recursos no decorrer do projeto e a aquisição de um componente de soft-
ware para adiantar o desenvolvimento.
Custos indiretos. São os custos associados indiretamente aos recursos do projeto em

termos de pessoas, treinamento, hardware, software, dentre outros.
Custos afundados. É o dinheiro que foi gasto no passado. Fazendo uma analogia, é
como um navio que já afundou depois de ser torpedeado e não tem mais jeito de re-
torná-lo à superfície e fazê-lo singrar pelos sete mares novamente. Quando for deci-
dir em quais projetos investir, não considere os custos afundados. É muito comum
em projetos de TI ocorrer o que chamo de retomada de proposta. Ou seja, um clien-
te solicita um estudo técnico da solução para o seu problema, passa uma documenta-
ção extensa informando como devem ser as regras de negócio e quais as suas necessi-
dades e o seu problema. Por ser um problema bem complexo, a sua organização en-
volve diversas pessoas, contrata um especialista pago a peso de ouro, leva um mês
para elaborar a proposta técnica e, por fim, entrega a proposta para o cliente. Depois
de toda a mobilização e o esforço da equipe, o cliente informa que o projeto será
abortado porque houve uma mudança repentina no mercado que o afetou e que será
retomado somente daqui a três meses quando ele espera encontrar o mercado mais
receptivo.
Teoria da curva de aprendizado. Significa que quando muitos itens são produzidos repe-
tidamente, a unidade de custo para esses itens vai diminuindo à medida que mais uni-

dades são produzidas. A teoria da curva de aprendizado deve ser utilizada para esti-
mativas de projetos envolvendo a produção de grandes quantidades de itens. Por
exemplo, um grande projeto de desenvolvimento orientado a objeto e componenti-
zado onde serão desenvolvidas centenas de classes, interfaces, subsistemas e compo-
nentes.
Reservas. São quantidades de dinheiro incluídas nas estimativas de custos para
eventuais situações não previstas. Normalmente em projetos de TI adota-se uma
margem mínima de 5% até no máximo 20%.
TCM – TOTAL COST MANAGEMENT

O TCM, ou gestão de custo total, é a aplicação efetiva de expertise técnico e profissio-
nal para planejar e controlar os recursos, custos, lucratividade e riscos. É uma abor-
dagem sistemática para gerenciar os custos através do ciclo de vida de qualquer em-
presa, programa, instalações, projeto, produto ou serviço.
A gestão de custo total é realizada através da aplicação de engenharia de custos, de
princípios de gestão de custos, de metodologias e gestão de processos.
Referências – Artigos
Para apoiar o leitor no aprofundamento deste assunto, segue abaixo uma lista com os
artigos e temas abordados na AACE International 50th Anniversary Meeting, reali-
zada em Las Vegas, de 19 a 22 de Junho de 2006.
“A Pragmatic Setup for Cost Estimation”, Mr. Junaid Ahcom, ICC, Mr. Shafi Uddin e Dr. Ali Ali
Shash.
“A Study of Advanced Project Control System for Korean Nuclear Power Plant Construction Pro-
ject”, Mr. Myung Youl Yoon e Mr. Jae Hee Han.
“Accurate Estimates In Less Than a Minute”, Mr. Glenn C. Butts, CCC.
“Allocating Damages in Construction Defect Cases”, Mr. David A. Norfleet, CCC.
“Applying Trapezoidal Technique in Resource Management”, Mr. Mark T. Chen, PE, CCE.
“Attracting and Retaining Project Resources”, Mr. Stephen L. Cabano.
“Authentic Community Concept Applied to A/E/C”, Mr. John Jeffrey Hannon.
“Bad Estimates Just Don’t Happen”, Mr. Joseph A. Lukas, PE, CCE.
“Bid Preparation Using Cost Templates and Range Estimating – An Equipment Manufacturer’s
Perspective”, Dr. Iqbal Noor, PE, CCE, Mr. Matthew Grumo, Mr. Matthew W. Kniskern e Mr.
Andrew Kopach.
“Capturing How Cost Engineers Think”, Mr. Oliver W. Houseman, Ms. Fiona Coley e Dr. Rajku-
mar Roy.
“Case Studies of the Decision-Making Process of Construction Clients”, Dr. Anthony J. Mills.
“Change Management for Today’s Projects – A Progress Approach”, Mr. Stephen E. Goodman.
“Choose Your Weapon (Selecting Estimating Tools and Databases)”, Mr. Todd Pickett, CCC.
“Claims Analysis Nested in Schedule Updates”, Mr. Christopher Willis Carson.
“Competency Development at an Owners Organization”, Mr. Paul Teklenburg e Mr. Sep Serfonte-
in.
“Concentrated Window Analysis Results”, Mr. Jeffery L. Ottesen, PE, PSP.
“Conceptual Planning of Highway Construction 3Projects”, Dr. Ahmed Hassanein P. Eng.

CAPÍTULO 3 107
“Construction Audit – An Essential Project Controls Function”, Ms. Alexia A. Nalewaik, CCE.
“Construction CPM Scheduling - Precision Without Accuracy”, Mr. Victor M. Ostrowski, PSP.
“Construction Productivity”, Mr. James D. Whiteside, II, PE.
“ConstructionManagement – Presumed Dead But Still Alive”, Mr. Talal Abi-Karam, PE, CCE.
“Core Competencies, Expectations and Career Path for an Estimating Professional”, Mr. John K.
Hollmann, PE, CCE e Mr. Bruce G. Elliott, CCC.
“Cost and Resource Management Using Primavera P3e”, Mr. Max Templeton.
“CPM Not Working Well On Small Projects”, Mr. Albert Joseph Kuhn, PSP.
“CPM Schedules – Why and How”, Mr. Satinder Singh Baweja, CCE.
“Daily Observation Reports Prevent Unwanted Costs”, Dr. William J. Bender, PE.
“Delay Analysis Considering Productivity”, Dr. Jae-Seob Lee.
“Development and Training of the Planning and Scheduling Professional”, Mr. Edward E. Douglas,
III, CCC, PSP.
“Displaying Complex Technical Data Graphically”, Mr. John C. Potter, PSP.
“Don’t Create Variances During Planning”, Ms. Leah V. Zimmerman, CCC, PSP.
“Earned Value Based Forecasts - Some Pitfalls”, Mr. Jan Evensmo e Dr. Jan Terje Karlsen.
“Economic Benefit of Natural Disaster Mitigation”, Mr. Jason Van Howell, CCE.
“Effective Construction Work Packages”, Mr. George Richard Gardner.
“Effective Presentation Skills for Cost Engineers”, Dr. Andrew F. Griffith, PE.
“Electronic Databases for Claims Analysis”, Mr. Joseph W. Wallwork, PE, CCE, PSP, Mr. Thomas
S. Sinacore, CCE PSP, e Mr. Eric Schatz.
“Estimate Reconciliations”, Mr. Barrett L. Richards, CCC, PSP.
“Estimating at Owner Companies”, Mr. Waymon D. Lofton.
“Estimating Design Fees for Transportation Projects”, Ms. Carla Lopez del Puerto, ICC, Dr. Dou-
glas D. Gransberg, PE, CCE e Mr. Kenneth F. Robson.
“Estimating in 3D: The Next Dimension”, Mr. Aziz Barmania e Mr. Leslie E. McMullan.
“Evaluating Contractor’s Early Involvement in Design”, Dr. Lingguang Song, Dr. Yasser Mohamed
e Dr. Simaan M. AbouRizk, P. Eng.
“EVMS Internal and DCAA Audit Recommendations”, Dr. Sean T. Regan, CCE.
“Facilities Maintenance Contracts Using R.S. Means Database”, Mr. Charles P. Woodward, PE,
CCE.
“Feasibility Studies:A Case For Using A Stochastic Approach”, Dr. Sabah Alkass, P Eng., Dr. Saad
Al-Jibouri e Mr. Vipha Techakosol.
“Financial Administration of Construction Contracts by Owners”, Mr. W. Doug Creech, CCC.
“Front-end Specifications: Tool or Trouble?”, Mr. Sidney J. Hymes.
“Fuel Cell Town: A Feasibility Study”, Mr. Iftikhar Kamil Madni, CCE.
“Global Experience of Benchmarking Facility Maintenance and Turnaround Contracted Services”,
Ms. Trudi Bissett e Dr. John G. Buchan.
“Heavy Civil & Infrastructure WBS”, Mr. Paul Martin Hewitt.
“Historical Data Practices of Construction Contractors”, Mr. John Jeffrey Hannon.
“How Accurate Are Your Estimates?”, Mr. Dan E. Schottlander, CCE.
“How to Create a World Class Project Management Organization”, Dr. Nick J. Lavingia, PE.
“Human Side of Project Management”, Mr. Madhu P. Pillai, CCC.
“Identifying As Built Completion Drivers”, Mr. Robert B. McCullough, PE, CCE e Mr. Satinder
Singh Baweja, CCE.
“Impacts of Project Change Management on Project Cost and Schedule Performances”, Mr. Yi Zou e
Dr. Sang-Hoon Lee.
“Implementing Risk Management on Transit Mega-Projects”, Mr. Shawn L. Kildare e Mr. George
P. Blank.

“Increasing Steel Price Effect on Equipment Price”, Ms. Laura Mayo e Ms. Raisa Nuryeva.
“Innovative Approaches to CPM Scheduling Management”, Mr. Russell P. Vakharia, CCE,
PSP.
“Is ‘Estimate Accuracy’ an Oxymoron?”, Mr. Larry R. Dysert, CCC.
“Is Your Job In Danger of Being Outsourced? Think Process Cost Control”, Mr. Rodney B. Adams,
CCE.
“Making CPM More Transparent”, Mr. Ronald M. Winter, PSP.
“Managing Project Cost Risk”, Dr. Dan Patterson.
“Measuring and Managing Cost Escalation”, Mr. Peter Morris e Mr. William F. Willson.
“Measuring Delay Using the Contemporaneous Period Analysis”, Mr. Mark F. Nagata, PSP.
“Modeling Labor Productivity in Steel Fabrication”, Dr. Lingguag Song e Dr. Simaan M. AbouRizk,
P. Eng.
“Performance Management: Making It Work”, Mr. Gary Cokins.
“Planning the Development of Your Estimate”, Mr. Christopher L. Kinney.
“Predicting Construction Duration of Building Projects”, Ms. Theresa Keoughan Burrows, Mr. Ian
Pegg e Mr. Joseph L.N. Martin.
“Project Documents and How They Influence Damages”, Mr. Patrick Steven Ray, CCC.
“Project Management During a Maoist Insurgency”, Dr. Enno Koehn, PE, Mr. Binod Basnet e Mr.
Pema Kumar Lama.
“Project Management Maturity Assessment”, Dr. Parviz F. Rad, PE, CCE e Dr. Ginger Levin
“Project Planning and Scheduling and its Impact to Project Outcome: A Study of EPC Projects in Ca-
nada”, Dr. Janaka Y. Ruwanpura, Mr. Tanveer Nabi Ahmed, Mr. Karim Kaba e Mr. Gerald Pa-
trick Mulvany.
“Project Risk Management Using Monte Carlo Simulation”, Mr. Mohamed K. Khedr, PSP.
“Proposed Specification Language Regarding Pacing”, Mr. Kenji P. Hoshino, PSP.
“Public Sector Project Total Cost Models”, Dr. John A. Kuprenas, PE.
“RDM – Relationship Diagramming Method”, Mr. Fredric L. Plotnick, PE.
“Relentless Trending – Key to Effective Cost & Schedule Management”, Mr. Nelson E. Bonilla,
CCE.
“Revitalizing Project Controls: A Roadmap to Excellence”, Mr. Christopher F. Michalak e Mr. H.
Lance Stephenson.
“Risk Analysis and Optimization of the (Un)Balanced Bid”, Mr. Jon Hoogenboom, PE, Mr. W Step-
hen Dale e Mr. Craig Martell.
“‘Root Causes’”: The Six Reasons for CHANGE”, Mr. Robert L. Tichacek, PE.
“Sarbanes-Oxley Act, Making the Case for Effective Project Management!”, Mr. Talal Abi-Karam,
PE, CCE.
“Schedule Analysis Indices”, Dr. Gary Rock Spencer PE e Ms. Rose Mary Lewis, PE.
“Scheduling Specifications for the 21st Century”, Mr. Paul Levin, PSP.
“Scheduling: The Good, the Bad and the Ugly”, Mr. H. Lance Stephenson, CCC.
“Scope Definition for Expanding Operating Projects”, Mr. Amitab Sharma, CCE e Mr. Chitram Lut-
chman.
“Selection of Estimating Software for the Process Industry”, Mr. Kevin McDowell, CCE.
“Significance of WBS in Contingency Modeling”, Mr. John Gengxin Zhao.
“So – Is this the Estimate?”, Mr. Kul B. Uppal, PE.
“The ‘Cool Hand Luke’ Theory of Project Communication”, Mr. William E. Kraus, PE, CCE.
“The Beach Boys Historical Landmark Project”, Mr. Harry W. Jarnagan PE, CCE.
“The Claims Consultant as a Peacemaker”, Dr. George F. Jergeas, P. Eng. e Mr. Stephen O. Revay,
CCC.
“The Cumulative Effect of Change”, Mr. Bob M. McCally.

CAPÍTULO 3 109
“The Great Negative Lag Debate”, By Mr. Edward E. Douglas III CCC PSP, Mr. Timothy T. Calvey
PE, PSP, Mr. Donald F. McDonald Jr. PE, CCE, PSP e Mr. Ronald M. Winter, PSP.
“The Link Between Planning and Programming Practice and the Analysis of Delay and Disruption
Claims”, Mr. Nuhu Braimah e Dr. Issaka Ndekugri.
“Using Artificial Neural Networks for Predicting the Outcome of Canadian Construction Litigated
Claims”, Mr. Amir Camille Chehayeb e Dr. Mohamed Al-Hussein, P. Eng.
“Using PRISM to Quantify Qualitative Data”, Dr. Flynn L. Auchey, PE e Dr. Gloria J. Auchey.
“Value Engineering for Hazardous Waste Projects”, Mr. Richard A. Selg, CCE.
“What’s in ISBL, OSBL, and The Factors?”, Mr. Christopher L. Kinney e Ms. Rafaele Gauche.
Para acessar os artigos na íntegra adquire as publicações “2006 AACE Internatio-

nal Transactions (em CD)” e “Total Cost Management Framework” disponíveis no
site https://www.aacei.org/bookstore/.
CONSIDERAÇÕES SOBRE TRIBUTOS

É sabido que os tributos (impostos, taxas e contribuições) representam importante
parcela dos custos das empresas, senão a maior. Com a globalização da economia,
tornou-se questão de sobrevivência empresarial a correta administração do ônus tri-
butário.
Conforme o IBTP (Instituto Brasileiro de Planejamento Tributário), em média,
33% do faturamento empresarial é dirigido ao pagamento de tributos. Somente o
ônus do Imposto de Renda e da Contribuição Social sobre o Lucro das empresas pode
corresponder a 51,51% do lucro líquido apurado. Da somatória dos custos e despe-
sas, mais da metade do valor é representada pelos tributos. Assim, é imprescindível a
adoção de um sistema de economia legal.
No momento de desenvolver os orçamentos dos projetos é importante considerar
os tributos e principalmente desenvolver um plano tributário para o projeto.
Abaixo cito uma lista dos tributos no Brasil e suas respectivas leis.
1. Adicional de Frete para Renovação da Marinha Mercante – AFRMM – Lei

10.893/2004
2. Contribuição à Direção de Portos e Costas (DPC) – Lei 5.461/1968
3. Contribuição ao Fundo Nacional de Desenvolvimento Científico e Tecnoló-
gico – FNDCT – Lei 10.168/2000
4. Contribuição ao Fundo Nacional de Desenvolvimento da Educação
(FNDE), também chamado “Salário Educação”
5. Contribuição ao Funrural
6. Contribuição ao Instituto Nacional de Colonização e Reforma Agrária
(INCRA) – Lei 2.613/1955
7. Contribuição ao Seguro Acidente de Trabalho (SAT)
8. Contribuição ao Serviço Brasileiro de Apoio a Pequena Empresa (Sebrae) –
Lei 8.029/1990

9. Contribuição ao Serviço Nacional de Aprendizado Comercial (SENAC) –

Lei 8.621/1946
10. Contribuição ao Serviço Nacional de Aprendizado dos Transportes
(SENAT) – Lei 8.706/1993
11. Contribuição ao Serviço Nacional de Aprendizado Industrial (SENAI) – Lei
4.048/1942
12. Contribuição ao Serviço Nacional de Aprendizado Rural (SENAR) – Lei
8.315/1991
13. Contribuição ao Serviço Social da Indústria (SESI) – Lei 9.403/1946
14. Contribuição ao Serviço Social do Comércio (SESC) – Lei 9.853/1946
15. Contribuição ao Serviço Social do Cooperativismo (SESCOOP) – art. 9, I,
da MP 1.715-2/1998
16. Contribuição ao Serviço Social dos Transportes (SEST) – Lei 8.706/1993
17. Contribuição Confederativa Laboral (dos empregados)
18. Contribuição Confederativa Patronal (das empresas)
19. Contribuição de Intervenção do Domínio Econômico – CIDE Combustíveis
– Lei 10.336/2001
20. Contribuição de Intervenção do Domínio Econômico – CIDE Remessas
Exterior – Lei 10.168/2000
21. Contribuição para Custeio do Serviço de Iluminação Pública – Emenda
Constitucional 39/2002
22. Contribuição para o Desenvolvimento da Indústria Cinematográfica Nacio-
nal – CONDECINE – art. 32 da Medida Provisória 2228-1/2001 e Lei
10.454/2002
23. Contribuição Provisória sobre Movimentação Financeira (CPMF) – Lei
9.311/1996
24. Contribuição Sindical Laboral (não se confunde com a Contribuição
Confederativa Laboral, vide comentários sobre a Contribuição Sindical
Patronal).
25. Contribuição Sindical Patronal (não se confunde com a Contribuição Con-
federativa Patronal, já que a Contribuição Sindical Patronal é obrigatória,
pelo artigo 578 da CLT, e a Confederativa foi instituída pelo art. 8º, inciso
IV, da Constituição Federal e é obrigatória em função da assembléia do Sin-
dicato que a instituir para seus associados, independentemente da contribui-
ção prevista na CLT)
26. Contribuição Social Adicional para Reposição das Perdas Inflacionárias do
FGTS – Lei Complementar 110/2001
27. Contribuição Social para o Financiamento da Seguridade Social (COFINS)
28. Contribuição Social sobre o Lucro Líquido (CSLL)
29. Contribuições aos Órgãos de Fiscalização Profissional (OAB, CRC, CREA,
CRECI, CORE, etc.)

CAPÍTULO 3 111
30. Contribuições de Melhoria: asfalto, calçamento, esgoto, rede de água, rede

de esgoto, etc.
31. Fundo Aeroviário (FAER) – Decreto-lei 1.305/1974
32. Fundo de Fiscalização das Telecomunicações (FISTEL) – Lei 5.070/1966
com novas disposições da Lei 9.472/1997
33. Fundo de Garantia por Tempo de Serviço (FGTS)
34. Fundo de Universalização dos Serviços de Telecomunicações (FUST) – art.
6 da Lei 9998/2000
35. Fundo Especial de Desenvolvimento e Aperfeiçoamento das Atividades de
Fiscalização (Fundaf) – art.6 do Decreto-lei 1.437/1975 e art. 10 da IN SRF
180/2002.
36. Imposto s/Circulação de Mercadorias e Serviços (ICMS)
37. Imposto sobre a Exportação (IE)
38. Imposto sobre a Importação (II)
39. Imposto sobre a Propriedade de Veículos Automotores (IPVA)
40. Imposto sobre a Propriedade Predial e Territorial Urbana (IPTU)
41. Imposto sobre a Propriedade Territorial Rural (ITR)
42. Imposto sobre a Renda e Proventos de Qualquer Natureza (IR – pessoa físi-
ca e jurídica)
43. Imposto sobre Operações de Crédito (IOF)
44. Imposto sobre Serviços de Qualquer Natureza (ISS)
45. Imposto sobre Transmissão Bens Intervivos (ITBI)
46. Imposto sobre Transmissão Causa Mortis e Doação (ITCMD)
47. INSS Autônomos e Empresários
48. INSS Empregados
49. INSS Patronal
50. IPI (Imposto sobre Produtos Industrializados)
51. Programa de Integração Social (PIS) e Programa de Formação do Patrimô-
nio do Servidor Público (PASEP)
52. Taxa de Autorização do Trabalho Estrangeiro
53. Taxa de Avaliação in loco das Instituições de Educação e Cursos de Gradua-
ção – Lei 10.870/2004
54. Taxa de Classificação, Inspeção e Fiscalização de produtos animais e vegetais
ou de consumo nas atividades agropecuárias – Decreto-lei 1.899/1981
55. Taxa de Coleta de Lixo
56. Taxa de Combate a Incêndios
57. Taxa de Conservação e Limpeza Pública
58. Taxa de Controle e Fiscalização Ambiental – TCFA – Lei 10.165/2000
59. Taxa de Controle e Fiscalização de Produtos Químicos – Lei 10.357/2001,
art. 16
60. Taxa de Emissão de Documentos (níveis municipais, estaduais e federais)

61. Taxa de Fiscalização da Aviação Civil – TFAC – Lei 11.292/2006

62. Taxa de Fiscalização CVM (Comissão de Valores Mobiliários) – Lei 7.940/1989
63. Taxa de Fiscalização de Vigilância Sanitária Lei 9.782/1999, art. 23
64. Taxa de Fiscalização dos Produtos Controlados pelo Exército Brasileiro –
TFPC – Lei 10.834/2003
65. Taxa de Fiscalização e Controle da Previdência Complementar – TAFIC –
art. 12 da MP 233/2004
66. Taxa de Licenciamento Anual de Veículo
67. Taxa de Licenciamento para Funcionamento e Alvará Municipal
68. Taxa de Pesquisa Mineral DNPM – Portaria Ministerial 503/1999
69. Taxa de Serviços Administrativos – TSA – Zona Franca de Manaus – Lei
9960/2000
70. Taxa de Serviços Metrológicos – art. 11 da Lei 9933/1999
71. Taxas ao Conselho Nacional de Petróleo (CNP)
72. Taxa de Outorga e Fiscalização – Energia Elétrica – art. 11, inciso I, e arti-
gos 12 e 13, da Lei 9.427/1996
73. Taxa de Outorga – Rádios Comunitárias – art. 24 da Lei no 9.612/98 e nos
art. 7 e 42 do Decreto 2.615/1998
74. Taxa de Outorga – Serviços de Transportes Terrestres e Aquaviários – art.
77, incisos II e III, a art. 97, IV, da Lei 10.233/2001
75. Taxas de Saúde Suplementar – ANS – Lei 9.961/2000, art. 18
76. Taxa de Utilização do MERCANTE – Decreto 5.324/2004
77. Taxas do Registro do Comércio (Juntas Comerciais)
78. Taxa Processual Conselho Administrativo de Defesa Econômica – CADE –
Lei 9.718/1998
Consulte a bibliografia a seguir para se aprofundar no assunto de tributos.*
Obras nacionais específicas

AMARAL, Gilberto Luiz do (org.). Planejamento Tributário & A Norma Geral Antielisão. Curitiba: Juruá
Editora, 2002.
BORBA, Cláudio. Direito Tributário: Teoria e 1.000 Questões. 20a ed. Rio de Janeiro: Campus/Else-
vier, 2006.
______. Processo Administrativo Tributário Federal e do INSS. Rio de Janeiro: Campus/Elsevier, 2004.
______. ICMS – Legislação Aplicável a Todos os Estados e Distrito Federal. Obra Atualizada e Comentada
com Jurisprudência e Exercícios. Rio de Janeiro: Campus/Elsevier 2006.
BORGES, Humberto Bonavides. Planejamento Tributário : IPI, ICMS, ISS e IR. 6a ed. revista, atualizada
e ampliada. São Paulo: Atlas, 2001.
______. Auditoria de Tributos : IPI, ICMS e ISS. 2a ed. São Paulo: Atlas, 2001.
______. Gerência de Impostos: IPI, ICMS e ISS. 3a ed. São Paulo: Atlas, 2001.
______. Curso de Especialização de Analistas Tributários. São Paulo: Atlas, 2001.
* Fonte: Portal Tributário – www.portaltributario.com.br

CAPÍTULO 3 113
BATISTA JUNIOR, Onofre Alves. O Planejamento Fiscal e a Interpretação no Direito Tributário. Belo
Horizonte: Melhoramentos, 2002.
CAMPOS, Cândido H. Planejamento Tributário. 2a ed. São Paulo: Atlas, 1985.
DÓRIA, Antônio Roberto Sampaio Dória. Elisão e Evasão Fiscal. 2a ed. São Paulo: Bushatsky, 1977.
GOYOS JR., Durval de Noronha et al. Paraísos Fiscais, Planejamento Tributário Internacional. São Pau-
lo: Observador Legal, 1988.
GRECO, Marco Aurélio. Planejamento Fiscal e Interpretação da Lei Tributária. São Paulo: Saraiva, 1998.
GUBERT. Pablo Andrez Pinheiro. Planejamento Tributário: Análise Jurídica e Ética. Curitiba: Juruá,
2001.
GUTIERREZ, Miguel Delgado. “Elisão e Simulação Fiscal”. Revista Dialética de Direito Tributário, São
Paulo: Dialética, n. 66, pp. 88-94, março de 2001.
HUCK, Hermes Marcelo. Evasão e Elisão: Rotas Nacionais e Internacionais do Planejamento Tributário.
São Paulo: Saraiva, 1997.
LATORRACA, Nilton. Direito Tributário: Imposto de Renda das Empresas. Atualizado até 31-12-99 por
Rutnéa Navarro Guerreiro e Sérgio Murilo Zalona Latorraca. São Paulo: Atlas, 2000.
MALERBI, Diva Prestes Marcondes. Elisão Tributária. São Paulo: Revista dos Tribunais, 1984.
MALKOWSKI, Almir. Planejamento Tributário e a Questão da Elisão Fiscal. São Paulo: Editora de Direi-
to, 2000.
MARTINS, Ives Gandra da Silva (org.). Elisão e Evasão Fiscal: Conferencista inaugural José Carlos Moreira
Alves. São Paulo: Resenha Tributária: Centro de Extensão Universitária, 1988 (Caderno de Pes-
quisas Tributária, vol. 13, vários autores, vários colaboradores).
______ e MENEZES, Paulo Lucena de. “Elisão Fiscal”. Revista Dialética de Direito Tributário, São Pau-
lo: Dialética, n. 63, dezembro de 2000.
PEREIRA, César A. Guimarães. Elisão Tributária e Função Administrativa. São Paulo: Dialética, 2001.
PRATES, Renato Martins. Interpretação Tributária e a Questão da Evasão Fiscal. Belo Horizonte: Del
Rey, 1992.
REVISTA DE ESTUDOS TRIBUTÁRIOS n. 5. Planejamento e Exigências Tributárias. Porto Alegre:
Síntese, janeiro/fevereiro de 1999.
ROCHA, Valdir de Oliveira (org.). Planejamento Fiscal: Teoria e Prática. Autores: Bernardo Ribeiro
de Moraes, Hugo de Brito Machado, João Dácio Rolim, Luciano Amaro, Natanael Martins, Val-
dir de Oliveira Rocha. São Paulo: Dialética, 1995.
______ (org.). Planejamento Fiscal: Teoria e Prática. v. 2. Autores: Ana Cláudia Akie Utumi, Hermes
Marcelo Huck, Hugo de Brito Machado, João Dácio Rolim, José Eduardo Soares de Melo, Luís
Eduardo Schoueri, Ricardo Mariz de Oliveira, Roberto França de Vasconcellos, Roberto Quiro-
ga Mosquera, Rutnéa Navarro Guerreiro, Sacha Calmon Navarro Coêlho. São Paulo: Dialética,
1998.
______ (org.). O Planejamento Fiscal e a Lei Complementar 104. Autores: Aurélio Pitanga Seixas Filho,
César A. Guimarães Pereira, Edvaldo Brito, Fábio Junqueira de Carvalho, Gabriel Lacerda Troia-
nelli, Hugo de Brito Machado, Ives Gandra da Silva Martins, João Dácio Rolim, João Francisco
Bianco, José Eduardo Soares de Melo, Marco Aurélio Greco, Maria Inês Murgel, Misabel Abreu
Machado Derzi, Ricado Lobo Torres, Ricardo Mariz de Oliveira, Sacha Calmon Navarro Coêlho.
Sidney Saraiva Apocalypse. São Paulo: Dialética, 2001.
ROLIM, João Dácio. Normas Antielisivas Tributárias. São Paulo: Dialética, 2001.
ROSA JR., Luiz Emydio F. da. Manual de Direito Tributário e Direito Financeiro: Jurisprudência Atualiza-
da. 14a ed. atualizada e ampliada. Rio de Janeiro – São Paulo: Renovar, 2000.
SCHOUERI, Luís Eduardo. Planejamento Fiscal Através de Acordos de Bitributação: Treaty Shopping. São
Paulo: Revista dos Tribunais, 1995.
TORRES, Heleno. Direito Tributário Internacional: Planejamento Tributário e Operações Transnacionais.
São Paulo: Revista dos Tribunais, 2001.

______. Pluritributação Internacional Sobre as Rendas de Empresas. 2a ed. revista, atualizada e ampliada.
São Paulo: Revista dos Tribunais, 2001.
VAZ, Carlos. Evasão Tributária. Rio de Janeiro: Forense, 1987.
XAVIER, Alberto. Tipicidade da Tributação, Simulação e Norma Antielisiva. São Paulo: Dialética, 2001.
Obras nacionais relacionadas com o tema

ALEMANHA. Novo Código Tributário Alemão. Com índices sistemático e analítico / apresentação do
Professor Ruy Barbosa Nogueira; tradução de Alfred j. Schmid et al. Rio de Janeiro: Forense; São
Paulo: Instituto Brasileiro de Direito Tributário, 1978.
AMARAL, Antonio Carlos Rodrigues do (org.). Curso de Direito Tributário. São Paulo: Celso Bastos
Editor, 2002.
ANDRADE FILHO, Edmar Oliveira. Manual do Imposto de Renda das Pessoas Jurídicas. 1a ed. São Pau-
lo: Atlas, 2000.
______. Direito Penal Tributário: Crimes Contra a Ordem Tributária. 2a ed. São Paulo: Atlas, 1997.
ATALIBA, Geraldo. Hipótese de Incidência Tributária. 4a ed. ampliada e atualizada. Em função da
Constituição de 1988. São Paulo: Revista dos Tribunais, 1990.
BACCARO, Renato Fernandes. Manual de Preços de Transferência: Uma Aplicação Prática Ante as Margens
de Lucro Predeterminadas. São Paulo: Hipótese / Baccaro / IBPT, 2002.
BALEEIRO, Aliomar. Limitações Constitucionais ao Poder de Tributar. 7a ed. revista. e complementada à
luz da Constituição de 1988 até a Emenda Constitucional n. 10/1996. Rio de Janeiro, Forense,
1997.
BECKER, Alfredo Augusto. Teoria Geral do Direito Tributário. 2a ed. São Paulo: Saraiva, 1972.
______. Carnaval Tributário. 2a ed. São Paulo: Lejus, 1999.
BORGES, Humberto Bonavides. Curso de Legislação Tributária para Concursos: IPI, II, IE, IR, CSL,
COFINS e PIS.
BRASIL. Congresso Nacional. CPI DA SONEGAÇÃO FISCAL. Pres. Jutahy Magalhães, Rel.
Ronan Tito. “Cadernos de Direito Tributário e Finanças Públicas, n. 9”. Revista dos Tribunais,
São Paulo, outubro/dezembro de 1994.
CARNEIRO, Daniel Araújo. Tributos e Encargos do Setor Elétrico Brasileiro: A Incidência Tributária nos
Contratos de Comercialização de Energia Elétrica. 1a ed., 2a tiragem. Curitiba: Juruá, 2002.
CARVALHO, Paulo de Barros Carvalho. Curso de Direito Tributário. 5a ed., atualizada. De acordo
com a Constituição Federal de 1988. São Paulo: Saraiva, 1991.
CASSONE, Vittorio, e CASSONE, Maria Eugenia Teixeira Cassone. Processo Tributário: Teoria e Prá-
tica. São Paulo: Atlas, 2000.
CASTRO, Alexandre Barros. Teoria e Prática do Direito Processual Tributário. São Paulo: Saraiva,
2000.
“Forma Impossibilidade no Direito Brasileiro Princípio da Legalidade”. Direito Tributário, São Paulo,
n. 55, janeiro/março de 1991, p. 180.
COIMBRA, José dos Reis Feijó. A Defesa do Contribuinte: (na esfera administrativa e na judicial, doutrina,
jurisprudência, legislação). Rio de Janeiro: Destaque, 1995.
CORRÊA, Antonio. Dos Crimes Contra a Ordem Tributária: comentários à lei nº 8.137, de 27/12/90. São
Paulo: Saraiva, 1994.
CHISTÓVÃO, Daniela e WATANABE, Marta. Guia Valor Econômico de Tributos. São Paulo: Editora
Globo, 2002.
DIAS, José do Nascimento e Nascimento, David Loureiro . Imposto de Renda Pessoa Jurídica: Legisla-
ção anotada. São Paulo: Atlas, 1997.
FABRETTI, Láudio Camargo. Contabilidade Tributária. 4a ed. São Paulo: Atlas, 1998.
______. Incorporação, Fusão, Cisão e Outros Eventos Societários: Tratamento Jurídico, Tributário e Contá-
bil.1a ed. São Paulo: Atlas, 2001.

CAPÍTULO 3 115
______. Direito Tributário para os Cursos de Administração e Ciências Contábeis. São Paulo: Atlas, 2002
______. Código Tributário Nacional Comentado. 3a ed. revista e atualizada. São Paulo: Atlas,
2001.
FOLMANN, Melissa. Sigilo Bancário e Fiscal: À Luz da LC 105/2001 e Decreto 3.724/2001. 2a ed. re-
vista e atualizada. Curitiba: Juruá, 2002.
GRECO, Marco Aurelio. Internet e Direito. São Paulo: Dialética, 2000.
MACHADO, Hugo de Brito. Temas de Direito Tributário II. São Paulo: Revista dos Tribunais, 1994.
LOPES. Rodrigo Fernando de Freitas. Crime de Sonegação Fiscal. Curitiba: Juruá, 2002.
LOVATTO, Alécio Adão. Crimes Tributários: Aspectos Criminais e Processuais. Porto Alegre: Livraria do
Advogado, 2000.
MACHADO, Brandão (org.). Direito Tributário: Estudos em Homenagem ao Prof. Ruy Barbosa Nogueira.
São Paulo: Saraiva, 1984.
MARINS, James. Princípios Fundamentais do Direito. São Paulo: Dialética, 1988.
MARTINS, Ives Gandra da Silva (org.). Tributação no Mercosul. Conferencista inaugural José Carlos
Moreira Alves. São Paulo: Revista dos Tribunais – Centro de Extensão Universitária, 1997 (Pes-
quisas tributárias. Nova Série; n. 3, vários autores, vários colaboradores).
______ (org.). Curso de Direito Tributário. São Paulo: Saraiva, 2000.
______ (org.). Contribuições de Intervenção no Domínio Econômico. São Paulo: Revista dos Tribunais,
2002.
______ e MARTINS, Rogério Gandra (org.). A Defesa do Contribuinte no Direito Brasileiro. São Paulo:
IOB, 2002.
MENEZES, João Carlos. Sonegação Fiscal: legislação e jurisprudência. 2a ed. Campinas: Bookseller,
1997.
MONTEIRO, Samuel. Tributos e Contribuições: tratado teórico e prático. São Paulo: Hemus – Tomo I.
______. Crimes Fiscais e Abuso de Autoridade. 1a ed. São Paulo: Hemus, 1993.
MORAES, Bernardo Ribeiro de. Compêndio de Direito Tributário. 2a ed. revista, ampliada e atualizada.
Rio de Janeiro: Forense, 1993.
MOSQUERA, Roberto Quiroga. Tributação no Mercado Financeiro e de Capitais. São Paulo: Dialética,
1998.
NASCIMENTO, Carlos Valder do (org.). Comentários ao Código Tributário Nacional : (Lei no 5.172, de
25.10.1966), Ives Gandra da Silva Martins et. al. Rio de Janeiro: Forense, 1997.
NOGUEIRA, Ruy Barbosa Nogueira. Curso de Direito Tributário. 15a ed. atualizada. São Paulo: Sarai-
va, 1999.
PEIXOTO, Marcelo Magalhães. Questões Atuais de Direito Tributário. São Paulo: iEditora, 2002.
______ (org.). IPTU : Aspectos Jurídicos Relevantes. São Paulo: Quartier Latin, 2002.
PONTES, Helenilson Cunha. O Princípio da Proporcionalidade e o Direito Tributário. São Paulo: Dialéti-
ca, 2000.
ROSA JR., Luiz Emydio F. da. Manual de Direito Financeiro & Direito Tributário: Jurisprudência Atualiza-
da. 14a ed. Rio de Janeiro/São Paulo: Renovar, 2000.
SOUZA, Luiz Carlos de. Contabilidade ao Alcance de Todos: um novo método de se aprender contabilidade.
Curitiba: Juruá, 2002.
VIEIRA, José Roberto. A Regra-Matriz de Incidência do IPI: texto e contexto. Curitiba: Juruá, 1993.
XAVIER, Alberto. Direito Tributário Internacional do Brasil: tributação das operações internacionais. 4a ed.
atualizada. Rio de Janeiro: Forense, 1995.
YOUNG, Lúcia Helena Briski. Imposto de Renda Pessoa Jurídica: Noções Fundamentais. 2a ed. atualizada.
______. Lucro Presumido. 2a ed. atualizada. Curitiba: Juruá, 2001.
______. Sociedades Cooperativa: Resumo Prático. 2a ed. atualizada. Curitiba: Juruá, 2002.
______. Imposto de Renda na Fonte. 3a ed. atualizada. Curitiba: Juruá, 2002.

______. Contribuições Sociais: Resumo Prático – PIS/PASEP, COFINS, CSLL, CIDE. 2a ed. atualizada.
______. Regimes de Tributação Federal: Resumo Prático – Simples, Lucro Real, Lucro Presumido, Lucro Arbi-
trado. 2a ed. atualizada. Curitiba: Juruá, 2002.
______. Guia Prático do Imposto de Renda Pessoa Física. 4a ed. atualizada. Curitiba: Juruá, 2002.
______. Simples Federal. 4a ed. atualizada. Curitiba: Juruá, 2002.
Obras estrangeiras relacionadas com o tema

ARESPACOCHABA, Joaquín de. Planificación Fiscal Internacional. Madrid: Marcial Pons, 1996.
AUSTRÁLIA. 1991 – International Tax Handbook.Australia, Horwath International, 1991.
AYALA, Jose Luiz Perez de. Las Ficciones en el Derecho Tributario. Madrid: Editorial de Derecho Fina-
ciero, 1970.
BEAUCHAMP, André. Guide Mondial des Paradis Fiscaux. Paris: Bernard Grasset, 1992.
BELTRAME, Pierre. La Fiscalité en France. 3a ed. mise à jour. Paris: Hachette Livre, 1993.
BILBAO, Antonio J. Como Pagar Menos Impuestos. Barcelona: Bruguera, 1981.
BOUTIN, Michel-Pierre. Guide Fiscal International: pays par pays: entreprises et personnes physiques. Pa-
ris: Éditions ESKA, 1991.
CARLOS, Américo Brás et. al. Guia dos Impostos em Portugal. Lisboa: Rei dos Livros, 1994.
COLLINS, Maurice H. “Evasion and Avoidance of Tax at the International Level”. In: European Taxa-
tion, n. 28, 1988.
COLLISON, David. Les Impôts en Europe. Paris: Éditions Belfond, 1995.
GARCÍA, Jesús Rivas. Fraude Fiscal: Inspección, economía experimental y estrategias. Madrid: Editorial
Kykinson, 1997.
GALLO, Franco. Elisão, Economia de Imposto e Fraude à Lei. Tradução de Zelmo Denari. Revista de Di-
reito Tributário, São Paulo, n. 52, pp. 7-18.
GIL, José Antonio e ROQUE, Susana. Cómo Pagar Menos a Hacienda. Madrid: Ediciones Perámide,
1998.
GIORCETTI, Armando. L’evasione Tributaria. Torino: Torinese, 1964.
HARRISON, D. Retirement Planning Handbook. 6a ed. Londres: Pitman Publishing, 1997.
INGLATERRA. The CCH Tax Handbook: 1999 – 2000. Londres: CCH Editions Limited, 1999.
LAMORLETTE, Thierry e RASSAT, Patrick. Stratégie Fiscale Internationale. 2a ed. Revista e amplia-
da. Paris: Maxima Laurent du Mesnil – Éditeur, 1995.
MARGAIRAZ, André. La Fraude Fiscale et Ses Succédanés: Comment on échappe à l’impôt... Blonay (Suis-
se), Editado por André Margairaz, 1994.
MASSON, Charles Robbez. La Notion D’Évasion Fiscale en Droit Interne Français. Paris: Livrairie Géné-
rale de Droit et de Jurisprudence – LGDJ. 1990.
PISTONE, Pasquale. Abuso del Diritto ed Elusione Fiscale. Gênova: Cedan, 1995.
SANTAMARIA, Baldassarre. La Frode Fiscale. Milano: Giuffrè, 1992.
SINCLAIR, Walter. Tax Guide: 1998-1999. Londres: Orion Books, 1998.
TINGLEY, Kenneth R. Income Tax Guide: 1999-2000. Londres: Orion Books, 1999.
VILLEGAS, Hector B. La Evasión Tributaria. Revista de Direito Mercantil, São Paulo, n. 25, julho/se-
tembro de 1973.
ZEITLIN, George. “Tax Avoidance, Tax Evasion (United States of America)”. In: Tax avoidance, tax
evasion: A survey of the treatment of tax avoidance ant tax evasion in the main industrialised countries of the
world. Londres: International Bar Association, Ed. Sweet and Maxwell, 2a ed., 1987.
UCKMAR, Victor (org.). Corso di Diritto Tributario Internazionale. Padova: Cedam, 1999.
______ (org.). Corso di Diritto Tributario Internazionale: Appendice: un <caso>. Padova: Cedam, 1999.

CAPÍTULO 3 117
O leitor poderá também acessar o site http://www.iob.com.br/ e conhecer o “IOB

Online”, lançado pela IOB Thomson em setembro de 2005: é o mais completo pro-
duto de informações online sobre a nossa legislação e suas aplicações. É uma ferra-
menta muito prática, que pode ser acessada via web e tem o seu conteúdo atualizado
em tempo real.
GESTÃO DE RISCOS1
Nos últimos anos, vem crescendo muito o uso do Project Management (gerencia-
mento de projetos) como uma maneira para as organizações industriais, comerciais e
governamentais atingirem seus objetivos. A filiação a associações internacionais de
gerenciamento de projetos vem crescendo exponencialmente; programas de
pós-graduação nessa área surgem por toda parte, e a Microsoft recentemente afir-
mou contar com mais de 5 milhões de usuários, no mundo todo, de seu software de
gerenciamento de projetos.
Toda essa maturidade, no entanto, não se reflete numa taxa mais elevada de suces-
sos. Garantir o sucesso dos projetos – entregar dentro do prazo e do orçamento pre-
vistos e com satisfação do cliente – continua sendo notoriamente difícil. A causa de
tantos fracassos é o fato de os projetos, em especial os de grande vulto, serem empre-
endimentos arriscados, por definição. Saber lidar com os riscos é um fator decisivo
para o sucesso ou fracasso do projeto.
Não é possível eliminar os riscos por completo, mas podemos nos esforçar para
reduzir a probabilidade de eles se concretizarem, ou para mitigar as suas conseqüên-
cias negativas. O objetivo da Gestão de Riscos no Project Management é identificar,
analisar, avaliar e tratar os riscos principais que podem afetar o projeto.
O primeiro estágio – identificar os riscos – é responsabilidade de cada participan-
te do projeto, desde os executivos seniores até os membros da equipe, o pessoal de
vendas e demais interessados diretos. Ao identificar os riscos, elimina-se o fator sur-
presa, aumentando assim a eficácia e a eficiência ao tratar as conseqüências. Entre as
ferramentas úteis para a identificação de riscos estão as sessões de brainstorming, os
checklists do setor, os relatórios de projetos já concluídos e a análise cuidadosa das
hipóteses básicas que nortearam o planejamento inicial. O resultado é um registro de
riscos, que contém uma descrição detalhada de todos os riscos identificados.
Na fase de análise e avaliação, os riscos identificados são classificados segundo a
probabilidade de ocorrência dos eventos associados a esses riscos e o impacto que te-
rão caso os mesmos se materializem. Na maioria dos projetos, eles são tão numero-
sos que não é possível tratá-los com o mesmo rigor. O propósito da avaliação de ris-
cos é priorizá-los. Uma estrutura chamada Matriz de Tolerabilidade de Riscos forne-
ce uma orientação para os esforços, distinguindo os riscos toleráveis dos intolerá-
1 Colaboração: Francesco De Cicco.

veis. O resultado é um registro priorizado de riscos. A avaliação precisa ser feita para
as três principais dimensões dos riscos de projetos: escopo (qualidade), prazos e re-
cursos (orçamento).
Na fase de tratamento dos riscos, implantam-se medidas para evitar ou reduzir os
riscos. Entre elas se incluem os planos de contingência, as ações para evitar os riscos,
as medidas para minimizar os riscos, a transferência dos riscos para terceiros e a acei-
tação dos riscos.
Os planos de contingência não controlam um risco diretamente, mas fornecem
planos prontos para serem implementados para minimizar os riscos. Esse é um exer-
cício muito útil, já que, segundo uma regra prática geralmente aceita, solucionar um
problema depois que ele ocorre é dez vezes mais caro do que desenvolver um plano
emergencial com antecedência.
Evitar um risco implica assumir uma via de ação totalmente diferente, que não
apresenta o mesmo nível de risco.
As medidas para minimizar os riscos podem reduzir a probabilidade de estes se
concretizarem ou atenuar as suas conseqüências negativas. O primeiro caso inclui
elaborar protótipos, quando grandes problemas podem ser identificados enquanto
se desenvolve uma versão reduzida do projeto. No segundo caso, podemos ter um
sistema de backup que entra em ação se o sistema principal falhar, ou ainda não esti-
ver operacional.
O produto final do processo de análise e avaliação de riscos é um registro prioriza-
do dos riscos, com atribuição de responsabilidades e definição de planos de ação.
Riscos de cronograma
Dos três principais objetivos do projeto – escopo, prazo e custo – o prazo vem rece-
bendo atenção cada vez maior, uma vez que a concorrência baseada em prazos obriga
as empresas a lançar produtos e serviços mais cedo, e a intervalos mais regulares.
Com isto, gerenciar os riscos que ameaçam o cronograma passa a ser crucial para o
sucesso do projeto. Todo gerente de projeto sensato sabe que os projetos nunca são
executados exatamente conforme o planejado e que os atrasos são inevitáveis.
Assim, o problema consiste em saber como administrar esses atrasos e como se recu-
perar depois que ocorrem.
Usando os processos descritos acima, o primeiro passo é avaliar o impacto poten-
cial dos atrasos. Para tanto, é preciso definir uma estimativa de prazos, com o melhor
cenário e o pior cenário para cada atividade, juntamente com o prazo esperado. Isso
permite calcular o resultado do pior cenário, no qual cada atividade teria a maior du-
ração possível. Com essa estimativa em mãos, teremos uma idéia básica da escala po-
tencial do problema. Contudo, embora muitas coisas realmente saiam errado num
projeto, não é provável que todas elas saiam errado. Assim, é necessário dar o segun-
do passo: a determinação das probabilidades. Para cada atividade, deve-se estabele-
cer a probabilidade de cada um dos possíveis prazos. Isso pode então ser expresso sob

CAPÍTULO 3 119
a forma de distribuição, com o prazo de cada atividade especificado como algum

ponto entre as estimativas de melhor e pior cenários, porém com maior probabilida-
de em torno do prazo mais provável.
Pode-se, então, realizar uma análise de simulações, examinando-se centenas ou
milhares de diferentes cenários, nos quais os prazos das atividades variam segundo
sua distribuição. Para essa análise, podemos usar ferramentas de software tais como
o Risk for Project, desenvolvido pela Palisade Corporation, que funciona em con-
junto com o Microsoft Project. O resultado é um espectro para a duração geral do
projeto, contendo as estimativas da probabilidade de se finalizar o projeto até uma
determinada data.
A análise de simulações também revela quais atividades são mais responsáveis pe-
los potenciais atrasos. O planejamento tradicional resulta na identificação de uma
trajetória crítica – uma seqüência de atividades, desde o início até o término do pro-
jeto, que determina a data de finalização do projeto; os atrasos em cada uma dessas
atividades críticas resultam num atraso do projeto. Embora o conceito de “atividade
crítica” seja extremamente útil, permitindo ao gerente de projeto concentrar-se
num conjunto limitado de atividades em vez de dispersar seu foco, eventos inespera-
dos podem mudar as atividades a serem identificadas como críticas. Podem ocorrer
grandes atrasos se o gerente de projeto continuar focado em atividades que no início
foram definidas como críticas, mas depois foram retiradas dessa categoria.
Usando a análise de simulações, pode-se checar quais atividades, nos cenários exa-
minados, são responsáveis pelos atrasos. Algumas delas serão críticas em todos os ce-
nários examinados; outras nunca serão críticas. Contudo, algumas serão críticas ape-
nas em determinados cenários. Estas também requerem um monitoramento atento,
pois embora não sejam críticas de início, podem se tornar críticas devido a atrasos
inesperados. A análise de simulações resulta no chamado Índice de Criticalidade
(Criticality Index), que indica a probabilidade de que uma atividade se torne crítica
com base no número de cenários nos quais ela constou como crítica. Os índices de
criticalidade podem então ser usados para priorizar a atenção ao monitorar as ativi-
dades em busca de atrasos.
A análise de simulações também pode revelar quais atividades contribuem mais para
os atrasos. Pode-se analisar se uma atividade provoca ou não impacto, e também qual a
severidade dele. Este último fator não é captado pelo índice de criticalidade, e depende
do risco inerente a cada atividade. As atividades que recebem maior pontuação nesse
aspecto também são chamadas de cruciais, para diferenciá-las das atividades críticas.
Entre 1993 e 2000, o Consórcio sueco-dinamarquês Oresund foi responsável pela
construção da maior ponte estaiada do mundo, ligando Copenhague, capital da Dina-
marca, à cidade de Malmo, na Suécia. Embora seja, sem dúvida, uma maravilha da enge-
nharia, o projeto se destaca especialmente por ter sido concluído dentro do orçamento e
cinco meses antes do prazo esperado. Desde o início, a equipe de gerenciamento do pro-
jeto buscou identificar as incertezas, quantificar as possíveis conseqüências de cada uma

delas, priorizar os riscos – tomando essa priorização como base do planejamento de ações
– e implantar planos de contingência. O foco era a data de inauguração, considerada críti-
ca para o sucesso do projeto. Foram usadas simulações para avaliar e tratar os riscos em
relação ao cronograma; uma análise inicial de riscos, realizada em 1993, mostrou que as
chances de se inaugurar a ponte em 2000 eram inferiores a 10%. Foram implantados pla-
nos para reduzir as principais incertezas, e as análises de riscos subseqüentes passaram a
mostrar uma chance cada vez maior de terminar no prazo. Em 1998, após um quarto
exercício de avaliação de riscos, os resultados positivos fizeram os gestores alterarem a
data de inauguração em cinco meses, e a ponte foi inaugurada em 1o de julho de 2000.
Embora a implementação da Gestão de Riscos tivesse um custo, este foi só uma fração do
benefício obtido ao se inaugurar a ponte antes do prazo previsto.
Gerenciamento de prazos suplementares

Além de acrescentar um prazo extra no final do projeto, entre a data esperada para a
conclusão e o prazo final projetado, também podem-se inserir prazos extras em pon-
tos específicos do cronograma, para evitar que um atraso inesperado prejudique a
entrega do projeto. Esses “buffer times”, ou prazos suplementares (reservas), devem
ser inseridos sempre que as tarefas críticas exigirem que se completem primeira-
mente os trabalhos não-críticos. Neste caso, deve-se garantir que haja uma margem
de segurança entre a tarefa não-crítica e a tarefa crítica que depende daquela. Esses
chamados “feeding buffers” são prazos extras que evitam que os atrasos em áreas
não-críticas atinjam também a trajetória crítica do projeto.
Riscos de orçamento
Os riscos orçamentários podem ser analisados de maneira semelhante aos riscos de
atraso no cronograma, com três estimativas de custo atribuídas a cada atividade: pes-
simista, otimista e provável. A análise das simulações revelará então os custos e as
contingências esperadas, de modo que o orçamento seja suficiente para cobrir des-
pesas inesperadas.
Riscos de portfolio de projetos

Os riscos embutidos nos projetos contribuem para o perfil geral de risco da empresa que
realiza o projeto. Portanto, o gerenciamento de riscos de projetos deve ser feito não só
para cada projeto individualmente, mas também para o portfolio geral da empresa.
A Gestão de Riscos do portfolio de projetos trata de tomar decisões sobre quais
projetos realizar, quais iniciar e quais eliminar, com base numa avaliação financeira e
estratégica dos benefícios esperados e dos riscos associados. Essa análise normalmen-
te se baseia numa análise do valor atual líquido, acrescida das análises de sensibilida-
de, de cenários e de simulações, através das quais se examinam e avaliam os riscos
técnicos e comerciais. Com base no apetite de riscos da empresa, é proposto um
portfolio específico de projetos.

CAPÍTULO 3 121
Pense, por exemplo, na indústria farmacêutica. A descoberta e o desenvolvimen-

to de novos remédios é um processo extremamente arriscado, caro e demorado. O
tempo médio que vai da descoberta da fórmula até o lançamento no mercado aumen-
tou para mais de 12 anos, e avaliações recentes indicam que o custo do desenvolvi-
mento de um remédio fica em torno de 1 bilhão de dólares.
A questão principal, porém, é a pequena chance de que uma droga em desenvolvi-
mento consiga chegar ao mercado. A maioria das drogas em desenvolvimento não
consegue passar pelos rigorosos processos científicos e regulatórios exigidos, e acaba
sendo eliminada. Além disso, apenas 30% das drogas que chegam ao mercado alcan-
çam o sucesso comercial necessário para recuperar os custos de desenvolvimento e
dar um bom retorno.
Grandes laboratórios como Pfizer, GlaxoSmithKline e Novartis têm processos
muito avançados de Gestão de Riscos do Portfolio – considerados um fator básico de
sucesso para criar e manter a lucratividade. Recentemente, empresas menores de bio-
tecnologia também adotaram a Gestão de Riscos, reduzindo consideravelmente os
enormes riscos em geral associados a esse tipo de companhia.
O ranking das ameaças*

Os riscos que mais desafiam os negócios – segundo pesquisa com 269 executivos de
empresas globais:
1. Reputação – Ameaças à imagem de produtos ou marcas

2. Regulatório – Desrespeito à legislação
3. Capital humano – Escassez de talentos e turbulências na sucessão
4. Tecnologia – Falhas operacionais e no sistema de segurança
5. Mercado – Desvalorização dos ativos
6. Crédito – Inadimplência dos clientes
7. País – Desafios específicos de uma região
8. Financiamento – Dificuldade de obter crédito
9. Terrorismo
10. Desastres naturais
Conclusão
A Gestão de Riscos de Projetos é uma ferramenta essencial para evitar numerosas in-
certezas e riscos que afetam o sucesso de um projeto. Há vários métodos e ferramen-
tas disponíveis capazes de auxiliar no processo de identificar, analisar, avaliar e tratar
os riscos de um projeto. Tais ferramentas incluem as matrizes de tolerabilidade de
riscos, registros de riscos, análises de cenários, análises de sensibilidade, simulações,
* Fonte: The Economist Intelligence Unit

índices de criticalidade e de crucialidade, prazos suplementares (buffers) e orçamen-

tos de contingência. O objetivo dessas ferramentas é aumentar as chances de com-
pletar o projeto dentro das expectativas de prazo e de custo, e com plena satisfação
do cliente – algo que se vê muito raramente nos projetos hoje em dia.
SEIS SIGMA2
A maioria dos benefícios do Seis Sigma reside exatamente na sua metodologia de im-
plementação e no uso correto e “sábio” das ferramentas e técnicas estatísticas que de-
vem ser utilizadas. Simplificações na aplicação da metodologia, como a redução do
número de pessoas treinadas e envolvidas no processo, podem acarretar resultados
decepcionantes, muito aquém do desempenho que o Seis Sigma pode efetivamente
propiciar.
Empresas como a Bombardier, GE, Polaroid, ABB e Seagate designaram um alto
executivo para, em tempo integral, conduzir, incentivar e supervisionar as iniciati-
vas Seis Sigma em toda a organização. O responsável pela estratégia deve desenvol-
ver um amplo plano para implementar e disseminar o Seis Sigma pela empresa. É ele
que deve selecionar os executivos (diretores e gerentes) que desempenharão o papel
de (“Campeões”) na organização. A principal responsabilidade deles é fazer com que
equipes multifuncionais se empenhem no desenvolvimento de projetos específicos
de melhoria e de redução de custos. Os Champions devem ser capazes de pavimentar
o caminho para as mudanças necessárias e para a integração de resultados.
São os Champions que definem as pessoas (ou a pessoa, dependendo do porte da
organização) que irão disseminar os conhecimentos sobre o Seis Sigma por toda a
empresa e irão coordenar uma determinada quantidade de projetos. Tais pessoas são
os (“Faixas Pretas”), que dedicam 100% de seu tempo ao Seis Sigma. Normalmente,
os Black Belts conduzem nas empresas de 4 a 6 projetos, por ano, que podem gerar
melhorias de US$ 75 mil a US$ 175 mil por projeto, em termos de redução de cus-
tos, melhoria dos tempos de ciclo do produto ou serviço, eliminação de defeitos e in-
cremento significativo da satisfação do cliente. A duração de cada projeto depende
da complexidade, da disponibilidade de equipamentos de medição apropriados e da
verba alocada para o mesmo.
A escolha de um candidato a Black Belt deve ser bastante criteriosa. Suas princi-
pais características pessoais devem ser as seguintes:
Ter experiência de pelo menos cinco anos em sua área de atuação (pode ser tan-
to engenheiro como administrador, por exemplo).
Ter sólidos conhecimentos de Estatística (não é necessário ser um especialista,
mas é imprescindível saber o que é média, desvio-padrão, teste de correlação,
análise de variância etc).
2 Colaboração: Francesco de Cicco.

CAPÍTULO 3 123
Ter excelente compreensão da língua inglesa (a maioria das publicações sobre o

Seis Sigma é em inglês).
Ser dinâmico e ter a firme disposição de efetuar mudanças (pessoas que ficam
esperando que lhes digam o que fazer não servem para ser Black Belts).
Ter habilidade para organizar e acompanhar projetos, e para coordenar equipes
de trabalho multifuncionais.
É fundamental, portanto, que o futuro “Faixa Preta” possua habilidades de lide-

rança. Um dos maiores desafios de um Black Belt é fazer com que outras pessoas pra-
tiquem novas formas de trabalho. Seu foco deve se concentrar em ensinar e auxiliar
os funcionários da organização na análise e controle dos processos em que os mesmos
atuam. Seu tempo deve estar voltado para estudar, pensar e aprender como inovar
na solução de problemas e no aumento da lucratividade.
Em grandes empresas, há também a figura do Master Black Belt, que, também em
tempo integral, assessora os Champions na identificação de projetos de melhoria,
além de coordenar todo o trabalho dos demais Black Belts.
Outro “personagem” do Seis Sigma são os chamados (“Faixas Verdes”), funcioná-
rios de toda a organização que dedicam apenas parte de seu tempo aos projetos Seis
Sigma. Eles têm menos responsabilidades no processo e normalmente se envolvem
em projetos diretamente relacionados ao seu dia-a-dia de trabalho. Os Green Belts
recebem uma versão mais simplificada do treinamento a que são submetidos os Black
Belts. Suas tarefas básicas podem ser resumidas de duas maneiras: auxiliar os Black
Belts na coleta de dados e no desenvolvimento de experimentos e liderar pequenos
projetos de melhoria em suas respectivas áreas de atuação.
O quadro a seguir oferece uma visão geral das características básicas dos principais
“personagens” da estratégia Seis Sigma.
CHAMPIONS BLACK BELTS GREEN BELTS

QUALIFICAÇÕES Diretores e gerentes. Formação superior. Experiência técnica e
Familiaridade com Sólidos conhecimentos administrativa.
Estatística. Familiaridade com
de Estatística.
ferramentas estatísticas
básicas.
TREINAMENTO Três dias de Quatro meses de Dois meses de
treinamento treinamento treinamento
(30 horas). (200 horas + projeto). (100 horas + projeto).
NÚMERO DE Um Champion por Um Master Black Belt Um Green Belt para
FUNCIONÁRIOS área-chave da para cada 30 Black cada
TREINADOS empresa. Belts (em grandes 20 funcionários.
empresas).

A metodologia DMAIC
Existem cinco fases ou estágios básicos para se obter o desempenho Seis Sigma em um
processo, divisão ou empresa. Elas são conhecidas pela sigla DMAIC: Define (definir),
Measure (medir), Analyse (analisar), Improve (melhorar) e Control (controlar).
Na fase Define, são identificados os projetos Seis Sigma que serão desenvolvidos na
empresa, com o objetivo primeiro de satisfazer as expectativas dos clientes em termos de
qualidade, preço e prazo de entrega. A habilidade da organização para atender a essa ex-
pectativa está intimamente ligada à variação de seus processos (queremos aqui nos referir
a qualquer tipo de processo, abrangendo tanto os administrativos ou transacionais, como
os de serviços, vendas e manufatura). A variação de processos tem um impacto direto nos
resultados financeiros da empresa em termos de custo, tempo de ciclo e número de defe-
itos, falhas e erros que afetam a satisfação do cliente. A identificação de projetos Seis Sig-
ma permite à organização reconhecer como os seus processos afetam sua lucratividade e
permite definir quais desses processos são críticos para o negócio da empresa.
A fase Measure abrange ações relacionadas à mensuração do desempenho de pro-
cessos e à quantificação da variabilidade dos mesmos. Através de consenso entre os
integrantes da equipe Seis Sigma da empresa, são identificadas as “Variáveis de Entra-
da de Processos-Chave” (KPIVs) e as “Variáveis de Saída de Processos-Chave”
(KPOVs). Nessa fase, são utilizadas ferramentas básicas como as métricas Seis Sig-
ma, a Análise de Sistemas de Medição (MSA), a Análise de Modos de Falha e Efeitos
(FMEA) e o Desdobramento da Função Qualidade (QFD).
Na fase Analyse, são analisados os dados relativos aos processos estudados, com o
objetivo principal de se conhecer as relações causais e as fontes de variabilidade e de
desempenho insatisfatório de tais processos, visando a melhoria dos mesmos. Nessa
fase, as ferramentas utilizadas incluem: visualização de dados, testes de hipótese,
análise de correlação e regressão, e análise de variância.
A fase Improve consiste, fundamentalmente, no desenvolvimento de Projetos de
Experimentos (DOE), com o objetivo de se conhecer a fundo cada processo, através
da mudança estrutural de níveis de operação de diversos fatores, simultaneamente,
do processo em estudo. A informação obtida com o DOE auxilia a identificar o ajuste
das variáveis-chave para modificar e otimizar o referido processo.
Na fase Control, são implementados diversos mecanismos para monitorar conti-
nuamente o desempenho de cada processo. Entre as técnicas adotadas, destacam-se
as seguintes: Cartas de Controle (Target Chart, Nominal Chart, Z Chart, CUSUM
Chart), Planos de Controle, Testes de Confiabilidade e Processos à Prova de Erros.
UPMM – UNIFIED PROJECT MANAGEMENT METHODOLOGY

A Metodologia Unificada de Gerenciamento de Projetos (UPMM – Unified Project
Management® Methodology) do IIL (www.iil.com.br) auxilia organizações a acessar
de forma fácil uma base de conhecimentos e utilizá-la para desenvolver e implemen-
tar sua própria metodologia de GP, aderente de uma só vez às boas práticas preconi-
zadas pelo PMI e às especificidades de seus projetos.

CAPÍTULO 3 125
O desafio dos negócios

Algumas dessas situações lhes soam familiares?
Inexistência de critérios claros para categorização e classificação dos projetos.
Falta de um método de gerenciamento unificado, que leve em consideração di-
ferentes tipos de projetos.
Ausência de exemplos de documentos que possam ser utilizados como templates
e que sejam facilmente acessíveis pelas equipes de projetos.
Desconhecimento sobre as principais fases e marcos de controle que um deter-
minado tipo de projeto deve ter.
Falta de clareza para toda a equipe envolvida quanto às definições essenciais de
escopo, tempo, custo e níveis de qualidade que o projeto deve alcançar.
Impossibilidade de customizar a metodologia adotada às especificidades dos vá-
rios empreendimentos da sua área ou organização.
Existência de inúmeras abordagens técnicas no desenvolvimento de um produ-
to ou solução (um software, por exemplo) sem unificação metodológica ou
correlação com as boas práticas de gerenciamento de projetos.
A solução UPMM do IIL

O IIL apresenta uma solução consistente para esses desafios, a UPMM – Unified Pro-
ject Management® Methodology (Metodologia Unificada de Gerenciamento de
Projetos). Trata-se de uma base de conhecimento em gerenciamento de projetos,
criada a partir da expertise do IIL como pioneiro e líder em GP ao longo dos seus 15
anos de existência, e que reúne todas as referências metodológicas necessárias para
que as equipes gerenciem e implementem projetos de forma bem-sucedida.
A UPMM é fácil de utilizar, porque tem uma interface simples e amigável, total-
mente aderente à Intranet da organização; é compatível com qualquer tipo ou porte de
empreendimento; e permite adaptações a processos e documentos específicos que já
sejam adotados com sucesso. Acima de tudo, a UPMM é 100% aderente às boas práti-
cas e aos processos de gerenciamento de projetos preconizados pelo Project Manage-
ment Institute (PMI), além de ser completamente adaptável aos software de acompa-
nhamento de projetos adotados pela organização, particularmente ao MS-Project.
Os benefícios da UPMM
Implementada rapidamente por toda a empresa
As equipes podem se concentrar em realizar seus projetos em vez de investir tempo
na aprendizagem de uma nova ferramenta. A UPMM é facilmente acoplável a qualquer
solução tecnológica de apoio à gestão de projetos, independentemente do fornecedor,
tais como Project Server, da Microsoft; Primavera; Módulo PS do R3/SAP, etc. A in-
terface da UPMM é amigável e de uso muito simples.

F I G U R A 3 . 3 Arquitetura de Integração de Ferramentas, Processos e Conhecimentos em um

Sistema EPM
Novo! Aderente ao PMBOK – Terceira Edição

O PMBOK – Terceira Edição está disponível; fácil de acessar de forma eletrônica, traz tem-
plates e checklists para cada etapa do processo de GP. Permite a aceleração da elevação da
maturidade em Gerenciamento de Projetos, uma vez que viabiliza a referência entre
processos adotados pela organização e as recomendações de boas práticas do PMI.
F I G U R A 3 . 4 Etapas dos Processos de GP

CAPÍTULO 3 127
F I G U R A 3 . 5 Passos da UPMM e Ciclo de Vida do Projeto
Automatiza ciclos de vida de projetos específicos (desenvolvimento de software,

Six Sigma etc.).
Com o apoio da UPMM, as diversas áreas da organização podem compartilhar uma
abordagem unificada de gerenciamento de projetos e combiná-la com seus processos
e documentos específicos – isto vale para qualquer ciclo de vida de processos, desde
o desenvolvimento de produtos até a implementação das técnicas do Six Sigma.
Algumas facilidades e benefícios da UPMM
Suporte a múltiplos tipos de projetos, com orientação para categorização, se-
qüenciamento de fases e marcos de controles para cada tipo de projeto definido
pela organização.
Mais de 250 templates, formulários e checklists de fácil edição (arquivos Micro-
soft) prontos para usar, com instruções de preenchimento e exemplos.
Alinhamento com o PMBOK – Terceira Edição, incluindo o PMBOK Guide Process
Project Type, que fornece templates e referências para as várias entradas, saídas e
ferramentas de cada processo, simultaneamente associados às nove áreas de co-
nhecimento (escopo, tempo, custos, qualidade, riscos, recursos humanos, co-
municação, integração e aquisições).

Base de conhecimentos com informações sobre as boas práticas do gerenciamento

de projetos, com destaque para os conceitos de papéis e responsabilidades, gover-
nança, gerenciamento de portfolio, melhoria contínua e Escritório de Projetos.
Estrutura para registro e disseminação das lições aprendidas e melhores práti-
cas em GP.
Mentor e FAQ para elucidação de dúvidas sobre gerenciamento de projetos.
Integração nativa com o MS Project 2002/2003.
Glossário completo dos principais termos.
Downloads
Novo: Faça o download do artigo “The Business Value of Embracing A Unified PM
Methodology” de George Pitagorsky, PMP. (http://www.iil.com/project_mana-
gement_training/UPPMM_Whitepaper_92304.pdf)
Novo: Faça o download da apresentação em PDF “UPMM Value Proposition”
(http:// www.iil.com/project_management_training/UPMM2%200-doc-to-
clients-2005-CD.pdf)
UPMM 2.0 FAQs (Perguntas mais freqüentes)
1. O que é UPMM™?
2. Como as empresas podem adquirir a UPMM™?
3. Como a UPMM™ é implementada? É difícil implementá-la por toda a organização?
4. O IIL provê treinamento em UPMM™?
5. Que tipo de tecnologia apóia a UPMM™?
6. As organizações podem hospedar a UPMM™? O IIL pode hospedá-la?
7. A UPMM™ pode ser customizada? Como?
8. A UPMM™ é capaz de incluir diferentes ciclos de vida, associados, por exemplo, a processos
departamentais?
9. A UPMM™ mantém aderência com tamanhos diferentes de projetos?
10. A UPMM™ fornece templates?
11. A UPMM™ é alinhada com o PMBOK® – Terceira Edição?
12. O que é o UPMM™ PMBOK® Guide Project Type?
13. A UPMM™ é aplicável a qualquer indústria?
14. A UPMM™ é multilíngüe?
15. A UPMM™ é integrada com o Microsoft® Office Project?
16. A UPMM™ pode ajudar na preparação para o Exame de Certificação PMP do PMI?
17. As empresas podem contatar usuários atuais da UPMM para medir seu sucesso?
18. Como posso agendar uma demonstração da UPMM?
19. Podemos ter uma prova grátis da UPMM™?
20. Uma vez implementada a UPMM™, as empresas conseguem ter apoio do IIL?
21. Quais são os pré-requisitos técnicos para a implementação da UPMM nas organizações?

CAPÍTULO 3 129
1. O que é a UPMM™?
A Metodologia Unificada de Gerenciamento de Projetos (UPMM) é uma base de
conhecimentos de GP aderente à Web, cujo destaque é o fornecimento de um guia
metodológico customizável para projetos de diferentes tipos e portes. Portanto, ela funciona
como uma referência metodológica para os projetos da organização, cujo planejamento e
controle continuarão a ser feitos pelas ferramentas adotadas na empresa, como por exemplo,
Project Server, Primavera etc.
2. Como as empresas podem adquirir a UPMM™?
A UPMM é adquirida através de licenças, a partir de um mínimo de 10 usuários (Licença Limitada),
até um número ilimitado (Licença Empresarial), de acordo com a necessidade do cliente.
3. Como a UPMM™ é implementada? É difícil implementá-la por toda a
organização?
A UPMM é uma solução baseada na Web, normalmente instalada na Intranet do cliente, num
processo muito simples e rápido, invariavelmente antecedido por um esforço de capacitação
em gerenciamento de projetos conduzido pelo IIL.
4. O IIL provê treinamento em UPMM™?
Sim. O IIL treinará seus administradores e usuários. Dentre os mais de 50 cursos que
compõem seu portfolio, o IIL tem alternativas de treinamento que provêem uma visão geral
sobre princípios fundamentais de gerenciamento de projetos integrado com um workshop
sobre como usar a UPMM.
5. Que tipo de tecnologia apóia a UPMM™?
A UPMM é baseada no Microsoft SQL Server.
6. As organizações podem hospedar a UPMM™? O IIL pode hospedá-la?
As organizações geralmente hospedam a UPMM em suas Intranet. Mas, dependendo do caso,
o IIL pode hospedá-la. Por favor, contate-nos para detalhes sobre esta opção.
7. A UPMM™ pode ser customizada? Como?
A UPMM é uma solução pronta para ser utilizada por organizações de qualquer porte. Ela já
traz um guia metodológico para projetos de três categorias genéricas: pequeno, médio e
grande portes. O cliente pode customizá-la a partir do portal de administração, definindo
atributos específicos para categorização de projetos, bem como incluindo documentos de sua
propriedade ou adaptando alguns dos mais de 250 templates já existentes na solução. A
inclusão de funcionalidades adicionais deve ser decidida pelo cliente e o IIL está apto a
customizar a UPMM deixando-a no formato final desejado.
8. A UPMM™ é capaz de incluir diferentes ciclos de vida, associados, por
exemplo, a processos departamentais?
Com o apoio da UPMM, as diversas áreas da organização podem compartilhar uma abordagem
unificada de gerenciamento de projetos e combiná-la com seus processos e documentos
específicos – isto vale para qualquer ciclo de vida de processos, desde o desenvolvimento de
produtos até a implementação das técnicas do Six Sigma.
9. A UPMM™ mantém aderência com tamanhos diferentes de projetos?
Sim. Por exemplo, há poucas etapas para os projetos menores e mais simples, e mais etapas e
documentos a serem preenchidos para os projetos maiores e mais complexos. O cliente da
UPMM também pode customizar a definição de etapas e marcos de projetos, de acordo com
as necessidades da sua organização.

10. A UPMM™ fornece templates?

Sim, a UPMM inclui mais de 250 templates, checklists e guias totalmente customizáveis de
forma autônoma pelo cliente. Essa customização é muito simples, pois trata-se de arquivos
Microsoft (Word, Excel, etc). Cada template é acompanhado de instruções de preenchimento,
assim como exemplos sobre como preenchê-los.
11. A UPMM™ é alinhada com o PMBOK® – Terceira Edição?
Sim, a UPMM™ é totalmente alinhada com o PMBOK – Terceira Edição.
12. O que é o UPMM™ PMBOK® Guide Project Type?
Todas as etapas do PMBOK – Terceira Edição, do PMI, estão organizadas nos grupos de processo
de Iniciação, Planejamento, Execução, Monitoramento e Controle, e Fechamento. O IIL, a
partir desta referência, criou templates para descrever integralmente todos esses processos e
incluiu-os na UPMM.
13. A UPMM™ é aplicável a qualquer indústria?
Sim, o Gerenciamento de Projetos é uma disciplina genericamente aplicável a qualquer
segmento de atividades. A UPMM tem sido implementada com sucesso em organizações
públicas, privadas e não governamentais, bem como nas mais variadas indústrias, tais como a
farmacêutica, de tecnologia da informação, comunicação, energia, saúde, telecomunicações,
financeira, imobiliária, de consultoria e serviços, entre outras.
14. A UPMM™ é multilíngüe?
A UPMM está disponível, atualmente, em inglês e espanhol. Em função da necessidade do
cliente, o IIL pode customizar a solução, incluindo a língua em que ela é apresentada.
15. A UPMM™ é integrada com o Microsoft® Office Project?
Sim. A UPMM é desenhada para ser integrada nativamente com o MS Project – com outras
ferramentas de GP, esta integração também pode acontecer de forma relativamente simples. O
objetivo é permitir a importação da metodologia customizada diretamente para as listas de atividades.
No caso do MS Project, essa integração já está presente a partir de um “add-in” que pode ser adquirido
separadamente e instalado na biblioteca do software para projetos de pequeno e médio portes.
16. A UPMM™ pode ajudar na preparação para o Exame de Certificação PMP do
PMI?
Sim. Por ser uma base de conhecimentos que inclui um guia de referência metodológica, a
UPMM é capaz de complementar e reforçar a capacitação em gerenciamento de projetos, uma
vez que tem uma biblioteca extensa de documentos e White papers que descrevem os tópicos
e processos de gerenciamento de projetos, bem como as áreas de conhecimento. Em relação à
preparação para o exame de Certificação do PMI, a UPMM traz o PMBOK Terceira Edição
eletronicamente, com a descrição de todos os seus elementos.
17. As empresas podem contatar usuários atuais da UPMM para medir seu sucesso?
Sim, o IIL pode dar referências, se solicitado.
18. Como posso agendar uma demonstração da UPMM?
Para agendar uma demonstração on-line, envie um e-mail para Norberto Almeida, PMP:
norberto.almeida@iil.com ou ligue para 21-3385-4106 / 11-3525-7533.
19. Podemos ter uma prova grátis da UPMM™?
Sim. Depois de assinar um Acordo de Confidencialidade, o IIL lhes dará acesso para a
ferramenta por alguns dias. Se você quiser fazer um “test drive”, entre em contato com
Norberto Almeida, PMP: norberto.almeida@iil.com ou ligue para 21-3385-4106 /
11-3525-7533.

CAPÍTULO 3 131
20. Uma vez implementada a UPMM™, as empresas conseguem ter apoio do IIL?
Sim, o IIL dá apoio aos clientes com todas as questões da UPMM relativas ao gerenciamento
de projetos, à metodologia da ferramenta e à tecnologia. O suporte aos usuários está
disponível on-line na própria UPMM. Sob acordos de manutenção, os clientes também
recebem upgrades da solução.
21. Quais são os pré-requisitos técnicos para a implementação da UPMM nas
organizações?
Hardware (servidor):
1.0 GHz or higher CPU (processor)
256 MB of RAM Memory (minimum)
2 GB of free Hard Drive Space
Ethernet Card ou other connectivity to LAN
Software (servidor):
Microsoft Windows 2000 (professional, Server or Advanced Server editions)
IIS (Internet Information Services) 5.0 or higher
SQL Server 2000 Service Pack 3 or Higher
MDAC 2.6 or Higher
Máquinas clientes:
Internet Explorer 4.0 or higher OR Netscape 6.0 or higher
JavaScript Enabled in Web Browser
Connectivity to client’s LAN
Links relacionados
KPMMM: http://www.iil.com/pm/Assessment_Tool_Demo/welcome.htm
(Modelo Kerzner de Maturidade em Gerenciamento de Projetos).
Project Pulse: http://www.iil.com/projectpulse/tour/default.htm
(Ferramenta para avaliar a saúde dos projetos).
Elibrary: http://www.iil.com/pm/elibrary/tour.asp
(a Biblioteca virtual de Gerenciamento de Projetos, que também inclui suporte
assíncrono à preparação para certificação PMP).
CONCLUSÃO
Neste capítulo constatamos como é importante estar atento aos aspectos de qualida-
de, recursos humanos custos, tributos, às melhores práticas e metodologias alinhas
com o PMBOK Terceira Edição de gerenciamento de projetos.
Gerentes de projetos antenados são aqueles que captam todos os sinais, conceitos,
ferramentas, práticas e tendências e ficam de olhos e ouvidos bem abertos em relação
às suas evoluções, eventos, publicações e principalmente a nobres iniciativas e movi-
mentos brasileiros e internacionais que estão vindo por aí!
O satélite dessa antena é o mundo dos negócios globalizado, um mercado extrema-
mente competitivo e em constante mudança.

O controle remoto (necessidades de sobrevivência) está em suas mãos para você selecio-
nar os melhores canais (práticas) de acordo com os melhores programas (mudanças)!
No próximo capítulo, veremos as peculiaridades dos projetos de tecnologia da in-
formação sob a ótica das nove áreas do conhecimento.

CAPÍTULO 4
As peculiaridades dos projetos de

tecnologia da informação sob a ótica
das nove áreas do conhecimento
INTRODUÇÃO
Neste capítulo, o leitor encontrará informações sobre as características peculiares
dos projetos de tecnologia da informação sob a ótica das nove áreas do conhecimento
que o PMI estruturou em seu Conjunto de Conhecimentos do Gerenciamento de
Projetos – o PMBOK.
Relembrando, as áreas do conhecimento estão divididas da seguinte maneira:
1. Gerenciamento da Integração
2. Gerenciamento do Escopo
3. Gerenciamento do Tempo
4. Gerenciamento dos Custos
5. Gerenciamento da Qualidade
6. Gerenciamento dos Recursos Humanos
7. Gerenciamento das Comunicações
8. Gerenciamento dos Riscos
9. Gerenciamento das Aquisições
A leitura deste capítulo é altamente recomendável para a compreensão geral do

contexto em que o livro se insere.

Áreas do Conhecimento
Conforme o PMI – PMBOK
Gerenciamento da
Integração
Gerenciamento do Gerenciamento do
Escopo Tempo
Gerenciamento dos Gerenciamento da

Custos Qualidade
Gerenciamento dos Gerenciamento das

Recursos Humanos Comunicações
Gerenciamento dos Gerenciamento das

Riscos Aquisições
F I G U R A 4 . 1 As Áreas do Conhecimento
O GERENCIAMENTO DA INTEGRAÇÃO EM PROJETOS DE TI

O gerenciamento da integração do projeto envolve a coordenação de todas as in-
terfaces e os processos das outras áreas do conhecimento através do ciclo de vida
do projeto.
Em projetos de TI, principalmente na área de software, esse tipo de gerenciamen-
to torna-se um pouco mais complexo porque a tecnologia está sempre em transição;
além disso, existe uma característica inerente a qualquer projeto, seja ele de TI ou de
outras naturezas: a incerteza.
Incerteza, nesse contexto, significa que será criado um produto ou serviço único,
nunca feito antes, e conseqüentemente, espera-se encontrar mudanças e desafios

AS PECULIARIDADES DOS PROJETOS DE TECNOLOGIA DA INFORMAÇÃO
CAPÍTULO 4 135
durante o planejamento e no decorrer do projeto que também nunca foram vivencia-

dos, sejam mudanças de escopo, tempo, custos, riscos ou outras áreas.
É preciso muito jogo de cintura para conseguir coordenar essas incertezas. Daí a
necessidade do gerenciamento de projetos e de um gerente de projetos.
Para a integração gerencial harmônica do todo, é necessário também, no início
dos projetos de TI, que o gerente receba o devido comprometimento da organização
e o suporte dos altos executivos. Os executivos devem delegar formalmente os res-
pectivos poderes, responsabilidades e atribuições para os gerentes de projetos. Esses
executivos devem estar cientes das características dos projetos de TI.
E, como estamos falando da coordenação do projeto como um todo, é muito im-
portante que essa integração seja feita sempre alinhada com os objetivos estratégicos
de negócio da organização, o que justifica a realização do projeto, o apoio dos execu-
tivos, o comprometimento da organização e a autoridade do gerente.
Alguém deve ser o responsável pela coordenação de todas as pessoas, dos planeja-
mentos e das tarefas necessárias para realizar o projeto. Além disso, alguém deve ter
uma visão geral do projeto para conduzir a sua equipe nessa direção. Alguém deve
analisar e tomar a decisão final quando houver conflitos nos objetivos do projeto ou
entre as pessoas envolvidas. Alguém deve informar o status do projeto para a gerên-
cia. Esse alguém é você, o gerente de projetos, e a ferramenta principal que você tem
em suas mãos é o gerenciamento da integração do projeto.
O gerenciamento da integração do projeto inclui também o gerenciamento das inter-
faces, que é a identificação e o gerenciamento dos pontos de interação entre os vários
elementos do projeto. O número de interfaces pode aumentar diretamente propor-
cional ao número de pessoas envolvidas no projeto. Portanto, uma das tarefas mais
importantes do gerente de projetos é estabelecer e manter boa comunicação e bom
relacionamento com as interfaces da organização.
O gerente de projetos deve se comunicar de forma efetiva com todos os envolvi-
dos no projeto, incluindo o cliente, a equipe do projeto, a alta gerência e outros ge-
rentes de projetos. Além disso, ele deve apresentar os resultados até mesmo para
aquelas pessoas que não eram a favor da realização do projeto. Cada um tem uma ne-
cessidade a ser comunicada, cabe ao gerente de projetos ser bem objetivo no mo-
mento em que ele estiver levando essas informações aos envolvidos.
Muitas pessoas consideram o gerenciamento da integração de projetos como a
chave para o sucesso geral do projeto. No campo da tecnologia da informação, um
bom gerenciamento da integração de projetos é um fator crítico para a satisfação de
todos os envolvidos.
O GERENCIAMENTO DO ESCOPO EM PROJETOS DE TI

A maioria das pessoas envolvidas com TI, mais especificamente com o desenvolvi-
mento de software, provavelmente já deve ter visto a seguinte figura:

F I G U R A 4 . 1 Requisitos Mal-compreendidos
Apesar de o produto final dessa seqüência ilustrativa parecer uma obra de arte de
Salvador Dalí, ela nos mostra que os requisitos do usuário não foram compreendidos
por todos os envolvidos no processo desde o início e que o resultado final não foi en-
tregue conforme ele esperava.
Problemas de escopo em projetos normalmente ocorrem por falhas de comunica-
ção e por fatores tais como a falta de envolvimento do usuário em todas as etapas do
projeto e a não-aderência do escopo e dos requisitos do projeto aos objetivos de ne-
gócio da organização.
Um dos mais importantes aspectos do gerenciamento de projetos é a definição do
escopo. Escopo refere-se a todo trabalho envolvido na criação dos produtos do pro-
jeto e os processos utilizados para criá-los, e deve ser baseado nos requisitos (necessi-
dades) do cliente (usuário).
Os envolvidos no projeto devem entrar num acordo sobre quais serão os produtos
do projeto e como serão produzidos antes de o projeto iniciar.
Uma vez definido e entendido por todos, o escopo do projeto deve ser formalizado
através de um documento que servirá como meta a ser atingida pelo time do projeto.
Quaisquer modificações solicitadas pelo usuário no escopo, sejam antes ou duran-
te o projeto, devem passar por um processo de avaliação de impactos, além de serem
tratadas de forma proativa pela gerência e equipe do projeto, que deve renegociar
com o cliente os aspectos da possível implementação.
Principalmente em projetos de desenvolvimento de software, tem-se uma visão
errônea de que é fácil mudar qualquer componente do aplicativo que seja visual ou
implementar uma nova funcionalidade que não estava prevista no escopo. Toda mu-
dança gera impacto. Por esses motivos, é bom que se gaste mais tempo definindo jun-
tamente com o usuário o escopo e a aparência que o aplicativo terá.

CAPÍTULO 4 137
O usuário deve ter a consciência de que, uma vez definido o escopo, não é interes-
sante ficar solicitando muitas alterações significativas no decorrer do projeto, só
porque surgiu uma nova tecnologia que ele gostaria de inserir no produto do proje-
to. Mudanças no escopo sempre causam impactos no projeto – replanejamentos,
alocações de mais recursos para implementá-las – e certamente custarão mais di-
nheiro tanto para o cliente quanto para o executor.
Em projetos de TI, em que novas tecnologias, plug-ins, add-ons surgem a cada
instante, é importante, antes de definir o escopo, fazer um questionamento exausti-
vo ao usuário para documentar aquilo de que ele realmente precisa. Também seria
interessante que você e a equipe do projeto fizessem uma pesquisa mais detalhada na
Internet ou em outros meios, para observar as tendências do mercado e verificar
quais tecnologias estão disponíveis no momento, como evoluirão nos próximos me-
ses e se tais tecnologias farão parte do escopo do projeto.
Antes de começar, sugiro que, na fase de definição, sejam feitas várias seções de
brainstorming com a equipe do projeto e com o usuário para que o escopo seja definido
com mais transparência e precisão e, principalmente, validado por todos.
Definir melhor o escopo significa também aumento na qualidade e na entrega do
produto final; além de otimizar o prazo do projeto, otimizam-se os custos e as aloca-
ções dos recursos.
Como recomendação final para projetos de TI, a definição de escopo, desde a des-
crição do produto e os requisitos dos usuários, deve ser feita sempre com a participa-
ção e o consentimento formal de todos os envolvidos no projeto.
O GERENCIAMENTO DO TEMPO EM PROJETOS DE TI

Muitos projetos de tecnologia da informação não obtêm sucesso por causa de proble-
mas nas projeções de tempo, que normalmente ocorrem devido a um mal-enten-
dimento dos requisitos do usuário, o que afeta diretamente a forma como o escopo
do projeto será definido.
Mais uma vez, estamos percebendo que todos os componentes do projeto estão
relacionados diretamente com saber identificar claramente as necessidades do clien-
te e com a definição bem-feita do escopo. Requisitos não-compreendidos totalmen-
te e escopos mal definidos causam grandes impactos problemas de estimativas de
tempo e afetam as outras áreas do projeto.
Os gerentes geralmente citam a entrega de seus projetos dentro do prazo como
sendo seu maior desafio.
De acordo com um estudo feito em 1995 nos Estados Unidos pelo Standish
Group, a média de prazos ultrapassados em projetos de tecnologia da informação
era de 222% acima da estimativa original. Ou seja, 222% de prazos ultrapassados
significa que, se um projeto foi planejado para levar um ano, ele terminou em 2,2
anos. Já em 2001, foi realizado o mesmo estudo e constatou-se que havia um con-
siderável declínio em relação ao ano de 1995, ou seja, o percentual de atraso caiu

para 63%. Nos dias atuais, muitos projetos ainda são finalizados depois dos pra-
zos estabelecidos.
Mas esse cenário pode mudar. Entregar um projeto no prazo é o principal desejo
do cliente que contrata projetos de tecnologia da informação, porque a janela de
tempo do produto gerado é muito pequena, ou seja, o ciclo de vida de um produto
de tecnologia da informação é curto; ele pode se tornar obsoleto em poucos meses
ou anos.
Além disso, existe o aspecto de o mercado ser extremamente competitivo, fazen-
do com que as organizações estejam sempre renovando e criando produtos com no-
vas funcionalidades, mais rápidos, mais práticos e com custos menores.
Gerentes também citam aspectos de cronogramas como sendo a principal razão
de conflitos ao longo dos ciclos de vida dos projetos. Durante a fase de concepção do
projeto, normalmente prioridades e procedimentos geram mais conflitos. Na fase
de desenvolvimento, somente as prioridades causam conflitos. Durante a fase de im-
plementação e na fase de fechamento, os conflitos tornam-se ainda maiores.
Parte dos problemas que ocorrem em cronogramas se deve ao fato de o tempo ser
facilmente medido. Pode-se debater mudança de escopo e aumento de custos e fazer
com que as estimativas cheguem próximas ao esperado; porém, uma vez estabeleci-
do o cronograma do projeto, você passa a ter uma data limite para entregar o proje-
to, e, com isso, qualquer um pode rapidamente estimar a performance do cronogra-
ma, calculando, a partir do prazo original, quanto tempo realmente levará para com-
pletar o projeto.
As pessoas geralmente comparam a finalização entre o planejado e o realizado sem
levar em conta o tempo que se gasta com as aprovações do projeto, ou seja, as homo-
logações que geralmente são feitas pelos usuários ou pelos patrocinadores ou analis-
tas facilitadores do projeto. Elas devem ser acordadas com o cliente e estimadas no
cronograma. Esse tempo não pode ser ignorado na hora do planejamento do crono-
grama; caso contrário, você terá sérias dificuldades na administração do tempo do
projeto.
É importante que o usuário tenha um prazo máximo para validar uma determi-
nada fase do produto do projeto. Se o usuário não validar o produto de acordo
com o prazo estabelecido no cronograma, o produto (ou a fase) será considerado
finalizado. Esse aspecto deve constar em contrato e deve ser acordado com o
usuário.
Seja em projetos de TI ou em projetos de outras naturezas, o tempo é a única va-
riável que não oferece flexibilidade, porque o tempo não pára, independentemente
do que acontece no projeto.
O cenário pode e deve mudar porque os processos de Gerenciamento do Tempo es-
truturados no PMBOK auxiliam os gerentes de projetos a estimarem prazos mais
realistas, evitando e minimizando problemas em outras áreas e fases do projeto.

CAPÍTULO 4 139
O GERENCIAMENTO DOS CUSTOS EM PROJETOS DE TI

Custo é um recurso sacrificado ou aquilo de que se abre mão para alcançar um objeti-
vo específico. Os custos normalmente são medidos em montantes monetários,
como Reais ou Dólares, que devem ser pagos para adquirir mercadorias, bens e ser-
viços.
Pelo fato de os projetos custarem dinheiro e redirecionarem recursos que pode-
riam ser aplicados em outras áreas, é muito importante para os gerentes de projetos
entenderem sobre gerenciamento de custos.
O gerenciamento de custos de projetos de tecnologia da informação é ainda mais
crítico, principalmente se for baseado em estimativas de custos em que os requisitos
e o escopo ainda não estão totalmente claros. Se nos relembrarmos das considera-
ções feitas no tópico sobre gerenciamento de escopo, poderemos concluir mais uma
vez que custo e escopo estão fortemente relacionados, e que dependem do entendi-
mento claro dos requisitos do usuário para serem estimados com mais precisão.
Escopos mal definidos por problemas de requisitos também mal-entendidos ge-
ram problemas de custos nas estimativas no início, no planejamento, na execução e
no controle do projeto; e, conseqüentemente, os custos no final do projeto tenderão
a aumentar muito e extrapolar o orçamento previsto.
Outra razão para a variação de custos em projetos de tecnologia da informação é
quando estes envolvem novas tecnologias. Qualquer tecnologia nova que ainda não
foi testada exaustivamente traz consigo riscos herdados. O ideal é não fornecer ne-
nhuma informação sobre o custo de projeto para o cliente sem antes validar por com-
pleto o entendimento dos requisitos e do escopo com os usuários e sem antes avaliar
as tecnologias disponíveis no momento. Esse processo deve envolver o gerente do
projeto, os membros do time e o usuário.
Falhas nas estimativas, variações e surpresas de custos podem ser evitadas e mini-
mizadas em projetos de tecnologia da informação se forem utilizados os processos de
gerenciamento dos custos, conforme estruturados no PMBOK.
O GERENCIAMENTO DA QUALIDADE EM PROJETOS DE TI

A qualidade dos projetos de tecnologia da informação está diretamente ligada ao
bom entendimento dos requisitos do usuário e à definição do escopo do projeto.
Uma vez mal definido um escopo, as chances de entregar um produto de má qualida-
de para o cliente são muitas.
Na visão do PMBOK, gerenciamento da qualidade “inclui os processos necessários
para garantir que o projeto satisfaça às necessidades para as quais ele foi empreendido”.
Em projetos de tecnologia da informação, um dos aspectos considerados como de
maior qualidade é a entrega do projeto dentro do prazo. É importante relembrar que
produtos gerados por tecnologia, principalmente de software, têm uma janela tem-
poral pequena devido às constantes renovações tecnológicas e à concorrência do
mercado.

Outro aspecto considerado como de qualidade é a entrega do projeto, seja ele ser-
viço ou produto, de acordo com o orçamento estimado. Ambos, tempo e custo, se-
rão mais bem gerenciados se o escopo tiver sido bem definido por todos os envolvidos
no projeto.
A qualidade está muito ligada ao sucesso. Uma prática interessante é saber do
cliente qual a sua visão sobre o sucesso do projeto. Alguns responderão que entregar
o produto ou serviço no prazo é um aspecto de sucesso, e que ele está disposto a in-
vestir mais dinheiro ou dividir os custos caso alguma mudança ocorra.
Outros serão mais flexíveis e responderão que entregar o projeto de acordo com
as estimativas de custos é um fator de sucesso, abrindo mão do prazo de entrega. Esse
tipo de visão auxilia o gerente de projetos tanto no gerenciamento da integração
quanto no gerenciamento da qualidade do projeto.
Muitos aspectos das nossas vidas cotidianas dependem de produtos de alta quali-
dade e de produtos de tecnologia da informação. Alimentos são industrializados e
distribuídos com a ajuda de computadores; alguns carros possuem chip para análise
de performance; nossos filhos utilizam computadores para ajudá-los na escola, pes-
quisar e fazer os seus trabalhos; nossas organizações dependem dos computadores; e
milhões de pessoas contam com o computador para o entretenimento e para se co-
municarem com outras pessoas através da Internet.
Muitos projetos de tecnologia da informação desenvolvem sistemas de mis-
são-crítica que são utilizados em situações de vida ou morte, tais como sistemas de
navegação a bordo dos aviões e componentes de computadores embutidos em equi-
pamentos médicos. Quando um desses sistemas não funciona corretamente, ocorre
muito mais do que um leve inconveniente.
Para melhorar a qualidade dos projetos de tecnologia da informação, é importante
entender os conceitos sobre o gerenciamento da qualidade de projetos e o desenvol-
vimento das modernas técnicas de gerenciamento da qualidade.
O GERENCIAMENTO DOS RECURSOS HUMANOS EM PROJETOS DE TI

Além dos clientes e dos produtos, sem dúvida alguma, os recursos humanos fazem
parte dos principais ativos das organizações. As pessoas movem as engrenagens da
produtividade. O sucesso dos projetos e também das organizações é determinado
pelas atitudes profissionais das pessoas.
Um dos maiores desafios dos gerentes de projetos, sejam eles de tecnologia da in-
formação ou de outra natureza, é gerenciar efetivamente os recursos humanos. Sa-
bemos que lidar com pessoas de diferentes raças, religiões, culturas e temperamen-
tos não é uma tarefa das mais fáceis. E hoje em dia, com a globalização, projetos en-
volvendo pessoas de diferentes países e culturas são uma situação comum.
Isso pode causar problemas de comunicação se os envolvidos não souberem se vi-
rar com a língua inglesa ou espanhola. Mas como hoje em dia saber o inglês é pré-re-
quisito para os profissionais de tecnologia da informação e praticamente para todo o

CAPÍTULO 4 141
mundo, o problema da comunicação é amenizado, já que existe um vocabulário e

jargões técnicos adotados globalmente.
Para gerenciar tais pessoas, o gerente de projetos tem de ser, acima de tudo, um
bom comunicador, dominar a língua inglesa, reconhecer e saber respeitar as diferen-
ças culturais. Por exemplo, existem religiões que não permitem que a pessoa traba-
lhe em um determinado dia. Esse aspecto deve ser observado e previsto pelo gerente
de projetos.
Outro aspecto a ser considerado pelo gerente de projetos é o processo de desmo-
bilização da equipe ao término do projeto. Desfazer uma equipe de um projeto que
durou, por exemplo, seis meses não é uma tarefa fácil, porque pessoas que convivem
juntas esse tempo normalmente criam vínculos de coleguismo ou amizade no decor-
rer do projeto. Uma tendência muito comum na fase final dos projetos é de as pes-
soas ficarem menos motivadas porque, de uma certa forma, não terão mais contato
umas com as outras. É muito importante o gerente observar atentamente esses com-
portamentos e saber motivar a equipe para não haver queda na produtividade.
Desmobilizar uma equipe traz consigo outro aspecto interessante e às vezes não
instituído pelo gerente de projetos. Você já pensou na troca de experiências que
acontece num projeto, por exemplo, de 12 meses com 20 recursos alocados? Você já
imaginou o conhecimento que se adquire no decorrer de um projeto? Por isso, o ge-
rente de projetos deve se preocupar em registrar as lições aprendidas pela equipe e ad-
ministrar o conhecimento da melhor maneira possível para que ele permaneça na or-
ganização.
É importante reservar uma parte do tempo de cada tarefa ou fase do cronograma
para documentar o que os recursos aprenderam ou, por exemplo, como eles resol-
veram tais problemas no decorrer do projeto.
Esse tempo pode e deve ser estimado no cronograma. Se devidamente cumprido
pelos recursos, o gerente terá uma documentação de tudo o que aconteceu ao final
do projeto.
As práticas de documentar as lições aprendidas e de administrar o conhecimento
da equipe tornam-se ainda mais necessárias e críticas quando se diz respeito a proje-
tos de tecnologia da informação, pois essas informações poderão ser utilizadas futu-
ramente, minimizando riscos, custos e escopos de projetos com tecnologias simila-
res.
Outro aspecto sutil que deve ser considerado pela organização e pelo gerente de
projetos é que pessoas qualificadas na área de TI são geralmente difíceis de se manter
por muito tempo nas organizações, principalmente quando se sentem insatisfeitas
por salários abaixo do mercado ou por falta de investimento da organização em sua
evolução profissional. Pessoas insatisfeitas geram improdutividade e má qualidade
no produto a ser desenvolvido pelo projeto. Sabemos que profissionais altamente
qualificados de TI são muito disputados no mercado, e, quando um recurso começa a
ficar insatisfeito, ele tende a procurar novos empregos sem mesmo sair do atual. Às

vezes ele utiliza até a própria intranet da organização para procurar empregos e dis-
ponibilizar seu currículo em sites especializados. Em algumas organizações, existe
um controle rígido através de um servidor Proxy para informar ao setor de recursos
humanos o acesso a tais sites e para saber quem está procurando por novos empregos.
Se isso acontecer, esteja certo de que a organização ou alguém do time do projeto
está insatisfeito.
Dependendo da situação, talvez, no momento em que você mais precisa do recur-
so, ele pede as contas, só porque encontrou uma empresa que paga melhor; e ações
como essa, se acontecem no decorrer do projeto, causam grandes impactos a ambos
os lados: cliente e organização executora do projeto.
O gerente de projeto deve estar o tempo inteiro atento a comportamentos estra-
nhos que demonstram a desmotivação de algum integrante do time do projeto. É
aquela velha história: uma maçã podre na caixa contamina todas as outras.
O gerente deve fazer uma reunião individual no início e no decorrer do projeto
para perceber se o recurso está motivado para trabalhar naquele projeto.
É normal e justo que as pessoas desejem receber salários compatíveis com o merca-
do e percebam que a organização oferece-lhes um ambiente propício para evoluir as
suas qualificações profissionais. Portanto, antes de determinar um salário para um fun-
cionário, analise bem suas qualificações, faça uma pesquisa salarial e ofereça um salário
compatível com o mercado, além de outros benefícios, tendo como objetivo fazer com
que ele estabeleça um vínculo profissional e pessoal mais forte com a organização.
Investir no capital humano é um dos diferenciais em relação à concorrência. É
crucial para as organizações praticarem o que elas pregam sobre recursos humanos.
Se as pessoas são realmente um dos seus maiores bens, as organizações devem traba-
lhar com tenacidade para atender às necessidades de seus recursos humanos. Organi-
zações agressivas (competitivas), além dos benefícios padrões, oferecem benefícios
diferenciados, tais como participações nos lucros, décimo quarto salário, bônus pe-
las metas alcançadas; incentivam funcionários a participarem de programas de trei-
namentos e certificações, além de investirem no pagamento de cursos MBAs e mes-
trados no Brasil e no exterior.
Esses benefícios motivam os funcionários, aumentando a qualificação, a perma-
nência e a produtividade desses profissionais nas organizações. É como se fosse um
programa de fidelização: o retorno é garantido e interessante para ambos.
Devemos pensar e olhar também para o futuro do Gerenciamento de Recursos Huma-
nos de TI. A necessidade de desenvolver futuros talentos em tecnologia da informação
tem importante implicação para todos.
Quem vai manter os sistemas que nós temos hoje?
Quem vai continuar a desenvolver novos produtos e serviços utilizando novas tec-
nologias?
Nobres iniciativas já estão sendo feitas nesse sentido: a maioria das escolas particula-
res e até algumas públicas estão incluindo em seus currículos matérias de informática.

CAPÍTULO 4 143
Para competirem nesse mercado dinâmico de tecnologia da informação, em que

novas tecnologias surgem diariamente, as organizações devem provisionar verbas
anuais e promover programas de treinamentos, planos de cargos e salários e incenti-
vos de certificação para seus funcionários.
Existem departamentos específicos que criam e estão sempre renovando uma gra-
de anual de treinamentos para os funcionários de acordo com cada função. Algumas
organizações até implantam universidades corporativas para a administração efetiva do
conhecimento dos seus funcionários. Dessa forma, o funcionário consegue vislum-
brar como ele poderá evoluir dentro da organização em termos de função, salário e
qualificação; e isso faz a grande diferença, faz o funcionário se sentir motivado.
Em algumas organizações mais agressivas, esses treinamentos são obrigatórios,
em outras, são sugeridos. Entretanto, como conselho, se você trabalha numa organi-
zação em que os cursos são obrigatórios, desenvolva uma maneira de se programar e
faça todos eles. Não perca essa oportunidade de demonstrar para os seus gerentes
que você tem interesse de se aperfeiçoar e de evoluir em sua função e de conseqüen-
temente aumentar a sua importância dentro da organização. Um salário melhor será
conseqüência do seu esforço.
O governo também pode ajudar muito no futuro dos recursos humanos de tec-
nologia da informação. Poderia ser criado um projeto, ou um programa (um con-
junto de projetos), em que se envolveriam os Governos Estaduais e as Prefeituras
Municipais, através de incentivos e convênios firmados com instituições de ensino
e organizações privadas, para levar até a população de baixa renda acesso às novas
tecnologias de hardware, software, Internet e cursos profissionalizantes gratuitos.
Dessa forma, estaríamos promovendo a democratização da informação tecnológi-
ca e formando novos talentos. Temos exemplos reais no Brasil de pessoas que saí-
ram de uma situação de baixa renda e hoje são famosas e milionárias. Tudo é uma
questão de oportunidade!
Se as organizações querem obter sucesso na implementação de projetos, sejam
eles de tecnologia da informação ou de quaisquer naturezas, elas precisam investir
muito e entender a importância do gerenciamento de recursos humanos, além de
agir proativamente para fazer o uso efetivo das pessoas.
O GERENCIAMENTO DOS RISCOS EM PROJETOS DE TI

Muitos estudos têm demonstrado que projetos de tecnologia da informação compar-
tilham alguns riscos em comum.
Por exemplo, o Standish Group fez uma pesquisa em 1995 chamada Unfinished Vo-
yages da qual participaram profissionais de tecnologia da informação na elaboração de
um questionário para saber o que determinava o sucesso de um projeto. Apesar de
essa pesquisa ter sido feita em 1995, o questionário permanece atual.
A tabela a seguir mostra o escore e a importância relativa dos fatores de critério
para o sucesso de projetos.

Critério de Sucesso Importância Relativa

Envolvimento do usuário 19
Suporte dos Executivos 16
Requisitos bem definidos 15
Planejamento apropriado 11
Expectativas realísticas 10
Milestones – Marcos ou pontos de controle de projetos menores 9
Equipe competente 8
Responsabilidade 6
Visões e objetivos claros 3
Trabalho pesado e equipe concentrada 3
Total 100
O Standish Group forneceu questões específicas para cada critério de sucesso a fim
de ajudar a decidir o número de pontos a serem designados. A seguir apresento essas
questões e seus critérios de pontuação.
Envolvimento do usuário
1. Tenho o usuário certo?
2. Quando envolvo o usuário? Antes ou sempre?
3. Tenho um bom relacionamento com o usuário?
4. Torno o envolvimento fácil?
5. Consigo descobrir de que os usuários necessitam?
A cada resposta positiva (sim) associe 3,8 pontos. Os pontos não podem passar de 19.
Suporte da Alta Gerência:
1. Tenho os executivos-chave?
2. Os executivos têm interesse nos resultados?
3. Falhas são aceitáveis?
4. Defini um bom plano?
5. O time do projeto tem interesse?
Requisitos bem definidos

1. Tenho uma visão concisa?
2. Tenho uma análise funcional?
3. Tenho uma estimativa de riscos?

CAPÍTULO 4 145
4. Tenho um case de negócio?

5. Posso mensurar o projeto?
A cada resposta positiva (sim) associe 3 pontos. Os pontos não podem passar de 15.
Planejamento apropriado
1. Tenho realmente um problema?
2. Tenho uma solução factível?
3. Tenho as pessoas certas?
4. Tenho uma sólida especificação?
5. Tenho milestones atingíveis?
Expectativas realísticas
1. Tenho expectativas claras?
2. Tenho priorização de necessidades?
3. Tenho milestones pequenas?
4. Posso gerenciar mudanças?
5. Posso prototipar?
A cada resposta positiva (sim) associe 2 pontos. Os pontos não podem passar de 10.
Marcos ou pontos de controle (milestones) de projetos menores:
1. Estou utilizando a regra 80/20? (na maioria dos projetos, 20% dos recursos
do projeto proverão 80% de benefícios para os usuários?)
2. Estou utilizando o design top-down?
3. Estou estimando limites de tempo?
4. Estou utilizando alguma ferramenta para prototipar?
5. Posso mensurar o progresso?
A cada resposta positiva (sim) associe 1,8 ponto. Os pontos não podem passar de 9.
Equipe competente
1. Conheço as habilidades ou conhecimentos necessários?
2. Tenho os recursos adequados?
3. Tenho um programa de treinamento?
4. Tenho incentivos?
5. A equipe se preocupará até o fim?

Responsabilidade
1. Tenho regras definidas?
2. Tenho uma organização definida?
3. Todos conhecem suas regras?
4. Incentivos estão associados ao sucesso do projeto?
5. Todos estão comprometidos?
Visões e objetivos claros

1. A visão está compartilhada?
2. A visão está alinhada com os objetivos da organização?
3. Os objetivos são alcançáveis?
4. Os objetivos são mensurados?
5. Os objetivos e as visões são constantemente verificados?
Trabalho pesado e equipe concentrada

1. Existem incentivos?
2. Estamos concentrados em entregas (deliverables) quantificáveis?
3. Todos trabalham juntos?
4. Estamos todos confiantes (seguros)?
Responder a essas questões do estudo elaborado pelo Standish Group é uma boa
oportunidade para exercitar e avaliar os riscos de um projeto de tecnologia da infor-
mação antes de iniciá-lo.
Outro questionário de riscos desenvolvido por F.W. McFarlan e Dayton Tire pode
ser utilizado para identificar as maiores fontes de riscos nas categorias de pessoas, es-
trutura e tecnologia.
Os riscos na categoria de pessoas incluem habilidades inadequadas (ambas geren-
cial e técnica), inexperiência geral e inexperiência numa área de aplicação específica
ou tecnologia.
Os riscos estruturais incluem o grau de mudança quando um novo projeto será
implantado nos departamentos dos usuários, no negócio da organização como um
todo, nos distintos grupos de usuários que estarão satisfeitos e o número de sistemas
com os quais o novo projeto terá de interagir.
Riscos tecnológicos envolvem a utilização de novas tecnologias ou de tecnologias
não testadas completamente.

CAPÍTULO 4 147
A tabela a seguir fornece alguns exemplos de perguntas do questionário sugerido

por McFarlan e Dayton.
Perguntas Peso
Qual é o tempo estimado para o projeto?
( ) Um ano ou menos Baixo = 1
( ) 13 meses até dois anos Médio = 2
( ) mais de dois anos Alto = 3
Qual a estimativa do número de recursos?
( ) Até 5 Baixo = 1
( ) de 5 a 15 Média = 2
( ) de 16 a 30 Médio = 3
( ) Acima de 30 pessoas Alto = 4
Número de departamentos envolvidos? (excluindo o departamento de tecnologia da informação)
( ) Um Baixo = 1
( ) Dois Médio = 2
( ) Três ou mais Alto = 3
Hardware ou software adicionais são necessários para o projeto?
( ) Nenhum Baixo = 1
( ) Mudança de processador Médio = 2
( ) Periféricos Médio = 3
( ) Novos computadores Alto = 4
( ) Mudança de plataforma, por exemplo, de PC para mainframes. Alto = 5
Você pode escolher mais de uma resposta. Após responder, multiplique o total de
pontos pelo peso da questão. McFarlan sugere a comparação dos escores em cada área
– pessoas, estrutura e tecnologia – para a maioria das organizações. Escores maiores
devem ser considerados como aviso para altos riscos.
Existem outros riscos que também são comuns a projetos de tecnologia da infor-
mação. São eles:
Risco de mercado. Se o projeto de tecnologia da informação criará um novo pro-
duto ou serviço, é viável que se faça uma pesquisa de mercado para saber se al-
guma outra organização não criará um produto ou serviço mais rápido e/ou
mais barato para os consumidores; ou se já existe um produto similar no merca-
do (evitando reinventar a roda e desperdiçar tempo e dinheiro à toa).
Risco financeiro. A organização tem condições de patrocinar o projeto? Quão
confiantes estão os envolvidos nas projeções financeiras do projeto? O projeto
trará retornos dos investimentos? Se não, a organização tem condições de con-
tinuar o projeto? Esse projeto é a melhor forma de a organização utilizar seus
recursos financeiros?
Risco de tecnologia. O projeto é tecnicamente factível? Hardware, software e rede
estarão funcionando adequadamente no decorrer e no término do projeto? A tec-
nologia pode se tornar obsoleta antes de o produto completo ser produzido?

Responder a essas perguntas e observar as origens dos riscos em projetos de tec-

nologia da informação é uma boa iniciativa antes de investir na realização de um novo
empreendimento.
Responder a essas perguntas é função da alta gerência e do gerente de projetos.
O GERENCIAMENTO DAS COMUNICAÇÕES EM PROJETOS DE TI

Recordo-me de um fato verídico, contado por um dos meus professores, em que
uma organização teve muitos problemas na reta final do projeto porque simples-
mente não fora perguntado, no início do projeto, se poderiam trabalhar depois das
18:30 h. Como a organização normalmente tinha um horário rígido de funciona-
mento, quando precisaram, simplesmente foi respondido que não era possível devi-
do a aspectos legais; e isso certamente causou impactos para a organização executora
do projeto. Esse é um fato típico de problema de comunicação.
Uma das maiores ameaças ao sucesso dos projetos, principalmente para projetos
de tecnologia da informação, refere-se a falhas de comunicação. Dentre os fatores
que geram problemas de comunicação, três merecem destaque:
O não-envolvimento do usuário em todas as etapas ou fases do projeto.

A falta de apoio dos altos executivos.
Levantamento de requisitos inconsistentes.
Conforme abordado anteriormente, se você não envolve o usuário desde o iní-

cio e em todas as fases do projeto, problemas de comunicação são normalmente vi-
venciados.
É aconselhável que nenhuma ação seja tomada em relação a, por exemplo, de-
finições de produtos e mudanças no escopo sem antes comunicar o fato ao usuá-
rio e principalmente sem documentar e ter seu aval. O usuário sempre deve par-
ticipar de todas as validações do projeto. A comunicação efetiva se dá através de
documentos que formalizam os aceites do usuário. Evite tomar decisões por te-
lefone.
Quando num projeto existe a falta de apoio dos altos executivos, problemas de
comunicação são facilmente identificados, principalmente quando esses executivos
não formalizam as responsabilidades e a autoridade do gerente do projeto. Para re-
forçar, eles devem tornar público para toda a organização esse apoio. Utiliza-se um
documento chamado Project Charter para reconhecer formalmente a autoridade do
gerente. Ele é a credencial do gerente de projetos.
Saber interpretar claramente quais são as necessidades do usuário é essencial para
uma comunicação efetiva. Os requisitos do usuário são os nossos primeiros contatos
com o seu problema ou com as suas necessidades, que nos propomos a resolver atra-
vés dos projetos e de seu efetivo gerenciamento.

CAPÍTULO 4 149
Requisitos bem levantados e principalmente bem documentados são importantes

para uma boa definição de escopo e, como tudo está interligado, certamente afetam a
performance do projeto em outras áreas do conhecimento e fases.
Outro aspecto importante que devemos considerar é que projetos envolvendo
tecnologia da informação não são realizados somente para os departamentos de TI
das organizações. Quando profissionais de tecnologia da informação precisam con-
versar com profissionais de outras áreas, alguns problemas de comunicação podem
ocorrer devido ao vocabulário globalizado e a jargões técnicos. Por esses motivos, é
bom evitar o uso excessivo de jargões principalmente no início, quando estão sendo
expostas as necessidades do usuário.
Conforme observado pelo meu Professor Danúbio Becker Borba (PMP), “O am-
biente de TI sempre foi arredio a influências externas de técnicas administrativas e,
assim, foi criando seu próprio mundo, uma forma especial de ser, herdado do tempo
dos antigos CPDs, verdadeiros departamentos cercados por uma redoma à qual o
restante da organização quase não tinha acesso. O índice de fracassos em projetos de
TI tem sido historicamente bem mais elevado do que nas demais áreas, devido a essa
‘rebeldia administrativa’. Um bom gerenciamento de comunicação de projetos re-
duz muito esses problemas de comunicação.”
Para aumentar ainda mais o problema de comunicação em projetos, o nosso sis-
tema educacional promove fortes habilidades técnicas para os cursos de graduação
em tecnologia da informação e promove menos habilidades de socialização e de co-
municação.
O ideal nesses cursos superiores de TI seria ter um balanceamento das habilidades
técnicas e das habilidades de comunicação, escrita, audição (o bom profissional sabe
ouvir), leitura, liderança, psicologia, sociologia, com o objetivo de preparar melhor
o profissional recém-formado para o mercado, uma vez que, assim, ele seria capaz de
expressar eficazmente as suas idéias.
Felizmente esse cenário está mudando com a disponibilização de cursos de
pós-graduação e MBAs, oferecidos por conceituadas instituições de ensino do Brasil.
Através da realização desses cursos, o profissional de TI pode obter as habilidades ne-
cessárias para se comunicar de forma mais efetiva. Mas os profissionais de TI “antena-
dos” e conscientes de que necessitam dessas habilidades não precisam esperar para
desenvolvê-las somente no ambiente acadêmico. Comece já! Na sua própria casa,
com a sua própria família!
Estudos mostram que tais habilidades são as mais necessárias para profissionais de
tecnologia da informação. Não podemos separar habilidades técnicas de habilidades
de comunicação quando trabalhamos com projetos de tecnologia da informação.
Para o sucesso do projeto, cada membro do time do projeto deve ter ambas as habili-
dades, e ambas devem ser continuamente desenvolvidas através de programas for-
mais de educação e através da experiência diária aprendida no ambiente de trabalho.

O GERENCIAMENTO DAS AQUISIÇÕES EM PROJETOS DE TI

Aquisição (Procurement) significa adquirir bens e serviços de uma fonte externa. O
termo aquisição é amplamente utilizado nos governos; muitas organizações privadas
utilizam o termo comprar; e profissionais de tecnologia da informação usam o termo
terceirizar.
Organizações ou pessoas que fornecem serviços de aquisições são referidos como
fornecedores, vendedores, subcontratados ou negociantes; porém, o termo mais
amplamente utilizado é fornecedores.
Muitos projetos de tecnologia da informação envolvem o uso de bens e serviços
que não procedem da organização. Devido ao fato de a terceirização ser uma área em
constante crescimento, é essencial para os gerentes de projetos entender a impor-
tância do gerenciamento das aquisições do projeto.
Muitas organizações estão migrando para a terceirização a fim de:
Reduzir custos fixos e recorrentes.

Permitir que a organização se concentre no seu negócio principal.
Obter acesso a habilidades e novas tecnologias através de contratação de con-
sultores terceirizados com larga experiência e especializados.
Flexibilizar equipes, evitando o desgaste e o remanejamento de equipes internas.
Aumentar a responsabilidade do fornecedor através de contratos bem escritos.
A terceirização de projetos de tecnologia da informação está crescendo a passos

largos. Por exemplo, muitas organizações terceirizam suas operações de administra-
ção de dados, de help desk (suporte) para outras organizações que são especializadas
nessas áreas.
Além disso, muitas organizações estão terceirizando seus projetos de tecnologia
da informação. Por exemplo, uma organização pode contratar uma grande firma de
consultoria para facilitar o desenvolvimento de um plano estratégico de tecnologia
da informação.
Outra organização pode querer contratar uma firma externa para desenvolver e
gerenciar suas aplicações de e-commerce. Essas necessidades específicas podem ser
atendidas por organizações externas durante longos períodos ou infinitamente.
As organizações também devem considerar as razões pelas quais não optarão pela
terceirização. Quando você terceiriza, geralmente não tem o controle suficiente so-
bre aqueles aspectos do projeto que somente fornecedores especializados possuem.
Além disso, você pode se tornar muito dependente de alguns fornecedores. Se es-
ses fornecedores vão à falência ou perdem pessoas-chave, isso pode causar muitos
danos para o seu projeto e, conseqüentemente, para o negócio da sua organização.
Outro aspecto essencial com o qual as organizações devem tomar muito cuidado é
não deixar informações estratégicas do projeto caírem em mãos erradas. Geralmen-
te, assina-se um Termo de Confidencialidade antes de iniciar o projeto ou inclui-se no

CAPÍTULO 4 151
contrato uma cláusula obrigando o contratado a não revelar, reproduzir, repassar,

exibir, divulgar, sob qualquer justificativa, as informações a que tiver acesso, bem
como manter a confidencialidade de informações que vierem a ser de seu conheci-
mento. O contratado deve declarar, ainda, estar ciente de que, na hipótese de viola-
ção do sigilo que ora se obriga a manter, durante o exercício de suas atividades, estará
sujeito às cominações legais aplicáveis na espécie.
Dependo do tipo do projeto, principalmente de tecnologia, se uma determinada
informação vazar para a concorrência, muitos podem ser os prejuízos.
O sucesso de muitos projetos de tecnologia da informação que utilizam recursos
externos é geralmente devido a um bom gerenciamento das aquisições do projeto.
A gerência do projeto deve considerar muito bem os aspectos envolvidos nas aqui-
sições do projeto de tecnologia da informação e tomar decisões sábias baseadas nas
necessidades únicas dos projetos e das prioridades de negócios das organizações.

PA R TE I I
Processos cronológicos
de gerenciamento de projetos

CONSIDERAÇÕES
A segunda parte deste livro, composta dos Capítulos 5, 6, 7, 8 e 9 trata dos grupos de
processos de gerenciamento de projetos de forma cronológica.
Relembrando, os processos de gerência estão divididos (agrupados) em cinco fa-
ses, da seguinte forma:
Iniciação
Planejamento
Execução
Monitoramento e Controle
Encerramento
Ao todo, de acordo com o PMBOK – Terceira Edição, os processos de gerenciamen-

to de projetos são 44, distribuídos nas respectivas áreas de conhecimento.
O modelo apresentado nesta parte do livro distribuirá esses 44 processos nas
cinco fases que representam todo o ciclo de vida do projeto. Será como uma receita
de bolo, ou seja, passo a passo, obedecendo a uma seqüência cronológica dos proces-
sos e das ações de gestão, desde o início do projeto até o seu encerramento. Cada
grupo de processo será abordado em um capítulo à parte.
Vamos, então, apresentar a seqüência cronológica dos processos de gerenciamen-
to de projetos de acordo com a nova versão do PMBOK – Terceira Edição.
Capítulo 5 – Processos de Iniciação

Desenvolver o termo de abertura do projeto (4.1)
Desenvolver a declaração de escopo preliminar do projeto (4.2)
Capítulo 6 – Processos de Planejamento

Desenvolvimento do plano de gerenciamento de projetos (4.3)
Planejamento do escopo (5.1)
Definição do escopo (5.2)
Criação da EAP (5.3)
Definição da atividade (6.1)
Seqüenciamento de atividades (6.2)
Estimativas de recursos da atividade (6.3)
Estimativa de duração da atividade (6.4)
Desenvolvimento do cronograma (6.5)
Estimativa de custos (7.1)
Orçamentação (7.2)
Planejamento da qualidade (8.1)
Planejamento de recursos humanos (9.1)
Planejamento das comunicações (10.1)

PROCESSOS CRONOLÓGICOS DE GERENCIAMENTO DE PROJETOS
PARTE II 155
Planejamento do gerenciamento de riscos (11.1)

Identificação dos riscos (11.2)
Análise qualitativa dos riscos (11.3)
Análise quantitativa dos riscos (11.4)
Planejamento de respostas a riscos (11.5)
Planejamento de compras e aquisições (12.1)
Planejamento contratações (12.2)
Capítulo 7 – Processos de Execução

Orientação e gerenciamento da execução do projeto (4.4)
Realização da garantia da qualidade (8.2)
Controle e mobilização da equipe do projeto (9.2)
Desenvolvimento da equipe do projeto (9.3)
Distribuição das informações (10.2)
Solicitação de respostas de fornecedores (12.3)
Seleção dos fornecedores (12.4)
Capítulo 8 – Processos de Monitoramento e Controle

Monitoramento e controle do trabalho do projeto (4.5)
Controle integrado de mudanças (4.6)
Verificação do escopo (5.4)
Controle do escopo (5.5)
Controle do cronograma (6.6)
Controle de custos (7.3)
Realização do controle da qualidade (8.3)
Gerenciamento da equipe do projeto (9.4)
Relatório de desempenho (10.3)
Gerenciamento das partes interessadas (10.4)
Monitoramento e controle de riscos (11.6)
Administração de contrato (12.5)
Capítulo 9 – Processos de Encerramento

Encerramento do projeto (4.7)
Encerramento do contrato (12.6)
Os números entre parênteses representam as respectivas referências ou seções no

PMBOK – Terceira Edição, para efeito de consulta ou pesquisa posterior. Por exemplo,
o processo Desenvolver o termo de abertura do projeto (4.1) pode ser encontrado no Capí-
tulo 4, seção 1.
Este livro pode e deve ser utilizado junto com o PMBOK – Terceira Edição para você
verificar e constatar a grande aderência das melhores práticas do PMI aplicadas à ges-

tão de projetos de tecnologia da informação. No PMBOK – Terceira Edição você en-

contrará todos os detalhes dos processos estruturados nas nove áreas do conheci-
mento, bem como as respectivas entradas, ferramentas e técnicas e saídas dos 44
processos de gerenciamento de projetos.
Para aprofundar-se nas suas pesquisas e na metodologia de gerenciamento de pro-
jetos do PMI, encorajo-lhe a adquirir um exemplar do PMBOK – Terceira Edição, já
traduzido oficialmente para o português, através do site “PMI Book Store” do PMI,
conforme URL a seguir: http://www.pmibookstore.org/
Feitas as devidas considerações, vejamos os processos de Iniciação no próximo ca-
pítulo.

CAPÍTULO 5
Processos de iniciação
INTRODUÇÃO
Vários são os estímulos para a realização de projetos, entre eles estão:
Aumento na competição
Uma demanda de mercado
Exigência de padrões de qualidade
Uma necessidade de negócio
Pressões econômicas
Um pedido do cliente
Um avanço tecnológico
Uma exigência legal
Uma necessidade social
Necessidade de sobrevivência
Mas antes de iniciar um novo projeto, é essencial que seja feito um estudo de viabili-
dade. O estudo de viabilidade avalia as condições atuais da organização para execução
do projeto. Além disso, ele verifica quais são os benefícios associados às demandas
dos projetos, com as recomendações dos planos de ação mais adequados para cada
caso. Um estudo de viabilidade pode conter os seguintes itens de verificação:
Se a necessidade ou problema do cliente tem solução.

Se o projeto está alinhado com o negócio da organização.

Se a organização possui profissionais tecnicamente qualificados para execução

do projeto.
A disponibilidade dos recursos que serão alocados no projeto.
A necessidade de contratação de profissionais terceirizados ou novos fun-
cionários.
Quanto a organização está disposta a investir.
A necessidade de assimilação de novos conhecimentos e realização de treina-
mentos para a execução do projeto.
Quais são os riscos implícitos e explícitos do projeto.
Descrição do cenário comercial entre a empresa executora e o cliente, levando
em conta os resultados dos projetos anteriores.
Identificação dos benefícios comerciais e os valores agregados que a execução
do projeto proporcionará.
É interessante tratar esse estudo de viabilidade como um projeto, com prazo de

execução e com um produto a ser entregue ao final do estudo; por exemplo, um re-
latório dando um parecer favorável ou não em termos técnicos, estratégicos, de aná-
lise financeira, de recursos humanos, de tecnologias disponíveis e de riscos para a
realização do projeto.
Depois de comprovada a viabilidade de execução do projeto, inicia-se uma fase de
propostas, em que são escolhidos os fornecedores e solicitadas as propostas técnica e
comercial das empresas executoras. Só depois dessas propostas serem aprovadas
pelo cliente é que se deve iniciar um projeto.
Antes de verificarmos as considerações e os resultados do processo de Iniciação,
eu gostaria de fazer uma breve observação em relação à proposta técnica.
Normalmente, ao elaborar uma proposta técnica de projetos de TI, já temos em
mãos os requisitos do usuário, ou seja, já sabemos quais são as suas necessidades; e,
através da proposta técnica, é apresentada ao cliente uma solução técnica para resol-
ver o seu problema.
Nessa etapa que precede o projeto, é possível otimizar o escopo do trabalho se os
requisitos do usuário estiverem bem documentados, transparentes e compreendi-
dos por todos os envolvidos.
Se existem dúvidas, estas devem ser tiradas neste momento; caso contrário, ocor-
rerão problemas de entendimento durante todas as fases do ciclo de vida do projeto:
iniciação, planejamento, execução, monitoramento e controle e encerramento.
Podemos enxergar essas ações preliminares como essencialmente necessárias
para uma gerência antecipada do grupo de processos de Iniciação do projeto.
Antes de começar o projeto, é importante que, além da fé e da certeza da vitó-
ria, você tenha em mãos a descrição do produto a ser desenvolvido, o plano estra-
tégico da organização, a definição dos critérios para seleção do projeto e informa-
ções históricas.

PROCESSOS DE INICIAÇÃO
CAPÍTULO 5 159
A descrição do produto documenta o serviço ou o produto de uma forma genéri-

ca, sem muitos detalhes nessa etapa.
Todo projeto deve estar alinhado com os objetivos estratégicos do negócio da or-
ganização – o plano estratégico da empresa deve ser sempre considerado como um
aspecto essencial nas decisões de seleção do projeto.
Considere o mnemônico SMART, usado em gerenciamento de projetos na fase de
definição dos objetivos de um projeto. É uma forma de avaliar se estes estão sendo
definidos de forma apropriada para o projeto. Um objetivo SMART deve ser:
Specific (específico)
Os objetivos e métodos são definidos de forma clara.
Measurable (mensurável)
Os objetivos são mensurados numericamente.
Achievable (realístico)
Humanamente possível, e o projeto tem todos os recursos necessários.
Relevant (relevante)
Evita-se a tentação de definir o objetivo somente porque ele se encaixou bem
nos três critérios anteriores.
Time framed (tempo)
Determinam-se prazos.
Não existe um consenso sobre o que significam precisamente as cinco palavras, ou

mesmo o que elas são. Algumas vezes R pode ser Realistic (realístico) ou Re-
sult-Oriented (orientado-a-resultado) no lugar de Relevant (relevante), Appropria-
te (apropriado) ou Action (ação) no lugar de Achievable (realístico).
Independendemente de haver consenso ou não, o mnemônico SMART tem-se
demonstrado ser uma boa técnica que pode ser utilizada na determinação dos objeti-
vos de um projeto.
Os critérios de seleção de um projeto são, tipicamente, definidos pelo retorno fi-
nanceiro, pelos valores agregados ao negócio, entre outros fatores.
As informações históricas envolvem os registros de situações ocorridas em outros
projetos da organização, cenários comerciais favoráveis ou desfavoráveis, as expe-
riências e lições aprendidas em projetos similares; até mesmo informações dos resul-
tados das fases anteriores podem ser levadas em conta.
Outro aspecto que precisa ser considerado antes de colocar a mão na massa é
submeter o projeto a uma avaliação especializada e formalizada por um consultor
especialista, uma pessoa que entenda do assunto. Essa avaliação pode ser feita por
pessoas da própria empresa, sejam do departamento de TI ou de outros departa-
mentos, ou por consultores terceirizados, a fim de garantir o respaldo técnico da
solução do projeto.

OS PROCESSOS DE INICIAÇÃO
O grupo de processos de Iniciação tem como objetivo a autorização e a obtenção do
comprometimento da organização para a formalização do início do projeto ou de uma
nova fase.
Os processos de Iniciação são: desenvolver o termo de abertura do projeto (4.1) e
desenvolver a declaração de escopo preliminar do projeto (4.2).
Desenvolver o termo de abertura do projeto (4.1)

Este processo tem a função de autorizar o projeto ou, em um projeto com várias fa-
ses, de autorizar uma de suas fases.
As entradas necessárias para desenvolver o termo de abertura do projeto são: o
contrato (quando aplicável), a declaração do trabalho, os fatores ambientais da em-
presa e os ativos de processos organizacionais.
As ferramentas e técnicas utilizadas para elaboração desse termo são: os métodos
de seleção de projetos, a metodologia de gerenciamento de projetos, o sistema de in-
formação do gerenciamento de projetos e a opinião especializada.
A saída deste processo é o próprio termo de abertura do projeto.
O termo de abertura do projeto é um documento que formaliza a existência do
projeto e autoriza o início de sua execução. Ele deve conter as necessidades do negó-
cio que o projeto está incumbido de tratar, a missão e os objetivos gerais do projeto,
além de uma breve descrição do produto do projeto. O termo de abertura do projeto
deve ser emitido e assinado por um gerente externo ao projeto.
O termo de abertura do projeto fornecerá autoridade para o gerente do projeto
utilizar todos os recursos da organização necessários para a devida condução do
projeto.
A gerência de comunicação pode começar também neste momento, quando todos
os gerentes da organização envolvidos (ou não) no projeto são notificados com o do-
cumento termo de abertura do projeto.
A notificação pode inicialmente ser via e-mail com o termo de abertura do
projeto anexado; depois, através de circulação de documentos internos ou de co-
municação visual, exibindo-o em murais da organização para todos terem acesso
à leitura.
Quanto mais cedo houver a designação do gerente do projeto, melhor. O ideal é
que o gerente seja designado antes de começar o projeto. O nome do gerente e a
identificação do projeto devem constar no termo de abertura do projeto, bem como
suas atribuições, responsabilidades e autoridade.
As pessoas precisam saber que Fulano de Tal é o gerente do projeto, e que a ele
foi confiada a autoridade e a missão de conduzir o projeto. Por isso, simbolicamen-
te, a partir daquele momento, ele passará a ser o condutor e deverá ser respeitado
como tal.

PROCESSOS DE INICIAÇÃO
CAPÍTULO 5 161
Em inglês é utilizado o termo Appointment Letter como título do documento para

designar a autoridade do gerente de projetos.
Você poderá adotar essas práticas e terminologias na sua organização ou optar por
uma terminologia própria. O importante é começar a utilizá-las, mesmo que seja
paulatinamente.
As restrições são aspectos que limitam as opções da equipe de gerência do projeto.
Por exemplo, um projeto com um orçamento predeterminado é um tipo de restri-
ção que muitas vezes pode até comprometer a qualidade dos profissionais contrata-
dos e, por conseguinte, a qualidade do produto final.
Outro exemplo de restrição seria: os consultores do projeto só poderão trabalhar
de 08:00h às 18:00h (nem mais, nem menos – estilo bater cartão), porque o horário
de funcionamento da organização é rígido.
Em projetos de TI, normalmente existem restrições de prazo e de tecnologia. No caso
desse último exemplo, vários poderão ser os impactos se as restrições não forem devida-
mente documentadas e gerenciadas bem de perto por todos os envolvidos no projeto.
Premissas são aspectos ou situações básicas relacionados ao objetivo do projeto que
contribuem para a sua devida condução. Um tipo de premissa pode ter relação com o
hardware; por exemplo, para a iniciação de um projeto de mudança de plataforma de
32 bits, será necessário que o cliente adquira servidores de 64 bits de marca e sistema
operacional diferente do atual parque de máquinas.
Todas as premissas e restrições devem ser documentadas no termo de abertura do
projeto.
Desenvolver a declaração de escopo preliminar do projeto (4.2)

A declaração de escopo do projeto é a definição do projeto, ou seja, o que será feito.
Esse processo deve documentar as características e limites do projeto e quail(is) pro-
duto(s) ele vai gerar.
Uma declaração de escopo deve incluir os itens a seguir: Objetivos do produto e
do projeto, Características e requisitos do produto ou serviço, Critérios de aceitação
do produto, Limites do projeto, Entregas e requisitos do projeto, Premissas, Restri-
ções, Riscos iniciais, Marcos do cronograma, WBS preliminar, Estimativa aproxi-
mada de custos e Requisitos de aprovação.
As entradas para desenvolver a declaração de escopo preliminar são: o termo de
abertura do projeto, a declaração do trabalho do projeto, os fatores ambientais da
empresa e os ativos de processos organizacionais.
As ferramentas e técnicas a serem utilizadas nesse processo são: a metodologia de
gerenciamento de projetos, o sistema de informação do gerenciamento de projetos e
a opinião especializada.
A saída desse processo é a própria declaração do escopo preliminar do projeto.

CONCLUSÃO
Vimos a grande importância dos processos de Iniciação: a autorização e a obtenção
do comprometimento da organização para a formalização do início do projeto ou de
uma nova fase.
O leitor perceberá nos próximos capítulos que as saídas de alguns processos de
Iniciação vão servir de entradas do grupo de processo de Planejamento, capítulo que
veremos a seguir.

CAPÍTULO 6
Grupos de processos
de planejamento
INTRODUÇÃO
Após ter sido escolhido e designado o gerente para o projeto, elaborado o termo de
abertura do projeto e a declaração de escopo preliminar do projeto, colhidas e docu-
mentadas todas as premissas e restrições, bem como todas as informações relevantes
e pertinentes ao processo de Iniciação, é hora de começar a planejar o projeto.
O planejamento é de vital importância para a condução efetiva do gerenciamento,
porque executar um projeto significa realizar um empreendimento único, nunca
executado anteriormente e, por isso, devemos caprichar no planejamento para ge-
renciar com maestria as incertezas. Por essa razão, existem mais processos nesta
fase. Contudo, ter um número maior de processos não significa que gerenciar proje-
tos seja essencialmente planejá-lo.
O volume de planejamento deve ser elaborado de acordo com as informações do
escopo do projeto. O planejamento deve ser visto como um esforço contínuo duran-
te todo o ciclo de vida do projeto.
OS PROCESSOS DE PLANEJAMENTO
De acordo com o PMBOK – Terceira Edição, o grupo de processos de Planejamento é
composto dos seguintes processos:



Orçamento (7.2)
Planejamento de contratações (12.2)

Este processo inclui as ações necessárias para definir, coordenar e integrar todos os pla-
nos auxiliares em um plano de gerenciamento do projeto. Este plano não é um docu-
mento estático. Ele deve ser atualizado constantemente no decorrer do projeto através
do processo Controle integrado de mudanças. Este plano dá o mapa da mina para o ge-
rente de projeto e sua equipe, pois ele mostra como o projeto será conduzido, monito-
rado, controlado e devidamente encerrado. Esse documento deve incluir mas não se
limitar aos seguintes itens: Processos de gerenciamento de projetos selecionados pela
equipe de gerenciamento de projetos, Nível de implementação de cada processo sele-
cionado, Descrições das ferramentas e técnicas a serem utilizadas no decorrer do pro-
jeto, Como o trabalho será executado para alcançar os objetivos do projeto, Como as
mudanças serão monitoradas e controladas, Como a linha de base será atualizada, Ne-
cessidades e técnicas de comunicação entre os stakeholders, Ciclo de vida do projeto,
Plano de gerenciamento do escopo, Plano de gerenciamento do cronograma, Plano de
gerenciamento de custos, Plano de gerenciamento da qualidade, Plano de gerencia-
mento de pessoal, Plano de gerenciamento das comunicações, Plano de gerenciamen-
to de riscos, Plano de gerenciamento de aquisições, Listas de marcos, Calendário dos
recursos, Linha de base do cronograma e dos custos e Registro de riscos.
As entradas deste processo são a declaração do escopo preliminar do projeto, os
processos de gerenciamento de projetos, os fatores ambientais da empresa e os ati-
vos de processos organizacionais.

GRUPOS DE PROCESSOS DE PLANEJAMENTO
CAPÍTULO 6 165
As suas ferramentas e técnicas são a metodologia de gerenciamento de projetos, o

sistema de informação do gerenciamento de projeto e a opinião especializada.
E a saída é o plano de gerenciamento de projeto.

O planejamento de escopo tem a função de criar um plano de gerenciamento do es-
copo do projeto que documenta como esse escopo será definido, verificado e con-
trolado e como a EAP (estrutura analítica do projeto ou WBS) será criada e definida.
As entradas deste processo são os fatores ambientais da empresa, os ativos de pro-
cessos organizacionais, o termo de abertura do projeto, a declaração preliminar do
escopo do projeto e o plano de gerenciamento do projeto.
As suas ferramentas e técnicas são os modelos, formulários, normas e opinião es-
pecializada.
E a saída é o plano de gerenciamento do escopo do projeto.

Agora que conhecemos mais informações sobre o projeto, é possível preparar uma
declaração de escopo detalhada do projeto que deve ser desenvolvida a partir das
principais entregas, premissas e restrições, que são documentadas durante a inicia-
ção do projeto. As necessidades, os anseios e as expectativas dos stakeholders são anali-
sadas e transformadas em requisitos.
As entradas deste processo são os ativos de processo organizacionais, a declaração
do escopo preliminar do projeto, o plano de gerenciamento do escopo e as solicita-
ções de mudanças aprovadas.
As suas ferramentas e técnicas são a análise de produtos, a identificação de alterna-
tivas, a opinião especializada e a análise das partes interessadas.
E as saídas são a declaração do escopo do projeto, as mudanças solicitadas e o plano
de gerenciamento do escopo (atualizações).
A declaração de escopo deve conter os objetivos do projeto, a descrição do escopo
do produto, os requisitos do projeto, os limites do projeto, as entregas do projeto, os
critérios de aceitação de produtos, as restrições do projeto, as premissas do projeto,
a organização inicial do projeto, riscos iniciais definidos, os marcos do cronograma,
as limitações de fundos, as estimativas de custos, os requisitos do gerenciamento de
configuração do projeto, as especificações do projeto e os requisitos de aprovação.

A EAP é uma estrutura decomposta hierarquicamente, orientada à entrega do trabalho
a ser conduzido pela equipe do projeto e que visa a alcançar os objetivos pelos quais ele
foi concebido. Ela organiza e define de forma visual o escopo total do projeto; e subdi-
vide o trabalho do projeto em partes menores, possibilitando um melhor gerencia-
mento e entendimento à medida que os níveis descendentes vão sendo detalhados.

F I G U R A 6 . 1 Exemplo de EAP (WBS)
As entradas deste processo são os ativos de processos organizacionais, a declara-

ção do escopo do projeto, o plano de gerenciamento do escopo do projeto e as solici-
tações de mudanças aprovadas.
As suas ferramentas e técnicas são os modelos de estrutura analítica do projeto e a
decomposição.
E as saídas são a declaração do escopo do projeto (atualizações), a estrutura analíti-
ca do projeto, o dicionário da EAP, a linha de base do escopo, o plano de gerencia-
mento do projeto (atualizações) e as mudanças solicitadas.
Existem outros tipos de EAP que podem ser utilizadas e são muito úteis para o en-
tendimento de outras disciplinas do projeto. Por exemplo, utilize uma EAC (estru-
tura analítica de custos) para ter uma visão geral, por fase e por entregas dos custos
do projeto. Utilize uma EAR (estrutura analítica de riscos) para ter uma visão hierár-
quica organizada dos riscos identificados do projeto ordenados por categoria de ris-
co. Utilize uma EAR (estrutura analítica recursos) para ter uma representação hie-
rárquica organizada dos recursos por tipo a ser utilizado no projeto.

A definição da atividade do cronograma tem a função de identificar e documentar o
trabalho planejado para ser realizado. Este processo identifica o nível e as entregas no
nível mais baixo da EAP. Esta entrega recebe o nome de pacote de trabalho. Estes pa-
cotes de trabalho são decompostos em partes menores, chamadas atividades do cro-

CAPÍTULO 6 167
nograma, para fornecer uma base para estimativas, elaboração de cronogramas, exe-
cução e monitoramento e controle do trabalho do projeto.
cessos organizacionais, a declaração do escopo do projeto, a EAP, o dicionário da
EAP e o plano de gerenciamento do projeto.
As suas ferramentas e técnicas são a decomposição, os modelos, o planejamento
em ondas sucessivas, a opinião especializada e o componente de planejamento.
E as saídas são a lista da atividade, os atributos da atividade, a lista de marcos e as
mudanças solicitadas.
O seqüenciamento das atividades envolve a identificação e a documentação das rela-
ções de dependência entre as atividades. Estas devem ser seqüenciadas de forma cor-
reta para a criação de um cronograma mais realista. Nos dias de hoje, utilizam-se am-
plamente ferramentas computadorizadas para seqüenciar as atividades.
As entradas deste processo são a declaração de escopo do projeto, a lista de ativi-
dades, os atributos de atividades, a lista de marcos e as solicitações de mudanças
aprovadas.
As suas ferramentas e técnicas são o método do diagrama de precedência (MDP),
o método do diagrama de setas (MDS), os modelos de rede do cronograma, a deter-
minação da dependência e a aplicação de antecipações e atrasos.
E as saídas são o diagrama de rede do cronograma do projeto, a lista de atividades
(atualizações), os atributos da atividade (atualizações) e as mudanças solicitadas.
Este processo envolve a determinação de recursos (pessoas, equipamentos ou mate-
riais) e a quantidade de todos os recursos que serão alocados e quando cada recurso
estará disponível para realizar as atividades do projeto.
cessos organizacionais, a lista de atividades, os atributos da atividade, a disponibilida-
de de recursos e o plano de gerenciamento do projeto.
As suas ferramentas e técnicas são a opinião especializada, a análise de alternativas,
dados publicados para auxílio a estimativas (acesse o site http://www.piniweb.
com/index.asp para mais informações), estimativa bottom-up.
E as saídas são os recursos necessários para a atividade, os atributos da atividade
(atualizações), a estrutura analítica de recursos (EAR), o calendário de recursos
(atualizações) e as mudanças solicitadas.
A estimativa de duração das atividades é o processo que determina o tempo das ativi-
dades para entrada do cronograma, a partir das informações do escopo do projeto e
dos recursos disponíveis.

A estimativa é progressivamente elaborada e vai se tornando cada vez mais preci-

sa. Essas estimativas devem ser feitas por pessoas mais experientes e familiarizadas
com os tipos de atividades em questão, e devem ser feitas levando-se em conta os di-
ferentes níveis de qualificação. Por exemplo, em um projeto de desenvolvimento de
software, o tempo para um analista programador sênior realizar uma determinada
tarefa deve ser diferente do tempo associado a um analista programador júnior para
realizar a mesma tarefa.
cessos organizacionais, a declaração do escopo do projeto, a lista de atividades, os
atributos da atividade, os recursos necessários para a atividade, os calendários de re-
cursos, plano de gerenciamento do projeto incluindo o registro dos riscos e as esti-
mativas de custos das atividades.
As suas ferramentas e técnicas são a opinião especializada, a estimativa análoga, a
estimativa paramétrica, a estimativa de três pontos e a análise de reservas.
E as saídas são as estimativas de duração da atividade e os atributos da atividade
(atualizações).

Desenvolver o cronograma significa determinar as datas de início e fim para cada ati-
vidade do projeto. Se as datas de início e fim não forem realistas, é bem possível que o
projeto não termine conforme o planejado.
O processo de desenvolvimento do cronograma deve ser conduzido de forma ite-
rativa, ou seja, considerando as estimativas das durações das atividades e estimativas
de custos, antes de efetivar o cronograma do projeto.
As entradas deste processo são os ativos de processos organizacionais, a declara-
ção do escopo do projeto, a lista de atividades, os atributos da atividade, os diagramas
de rede do cronograma do projeto, os recursos necessários para a atividade, os calen-
dários de recursos, as estimativas de duração da atividade e o plano de gerenciamen-
to do projeto incluindo o registro de riscos.
As suas ferramentas e técnicas são a análise de rede do cronograma, o método do
caminho crítico, a compressão do cronograma, a análise de cenário do tipo “e se?”, o
nivelamento de recursos, os métodos da cadeia crítica, o software de gerenciamento
de projetos, a aplicação de calendários, o ajuste de antecipações e os atrasos e mode-
los de cronogramas.
E as saídas são o cronograma do projeto, os dados do modelo de cronograma, a li-
nha de base do cronograma, os recursos necessários (atualizações), os atributos da
atividade (atualizações), o calendário de projeto (atualizações), as mudanças solicita-
das e o plano de gerenciamento do projeto (atualizações) contendo o plano de geren-
ciamento do cronograma (atualizações).

CAPÍTULO 6 169

A estimativa dos custos tem o objetivo de realizar um orçamento prévio dos custos
dos recursos necessários para executar e completar as tarefas do projeto.
Através das estimativas de custos, é possível desenvolver alternativas de cus-
tos e elaborar uma avaliação quantitativa dos resultados prováveis de quanto cus-
tará para a organização o fornecimento do produto ou o serviço a ser desenvolvi-
do no projeto.
cessos organizacionais, a declaração do escopo do projeto, a EAP, o dicionário da
EAP e o plano de gerenciamento do projeto, contendo o plano de gerenciamento do
cronograma, o plano de gerenciamento do pessoal e o registro de riscos.
As suas ferramentas e técnicas são a estimativa análoga, determinar os valores de
custo de recursos, estimativa bottom-up, estimativa paramétrica, software de geren-
ciamento de projetos, análise de proposta de fornecedor, análise de reservas e custo
da qualidade.
E as saídas são as estimativas de custos da atividade, os detalhes que dão suporte à
estimativa de custos da atividade, as mudanças solicitadas e o plano de gerenciamen-
to de custos (atualizações).
Orçamento (7.2)
O objetivo do orçamento é alocar as estimativas dos custos globais às atividades indi-
viduais dos pacotes de trabalho, com a finalidade de estabelecer uma linha de base de
custo para medir o progresso do projeto. As estimativas devem ser elaboradas antes
de se submeter o orçamento para aprovação.
As entradas deste processo são a declaração do escopo do projeto, a EAP, o dicio-
nário da EAP, as estimativas de custos da atividade, os detalhes que dão suporte à es-
timativa de custos da atividade, o cronograma do projeto, o calendário de recursos,
o contrato e o plano de gerenciamento de custos.
As suas ferramentas e técnicas são a agregação de custos, a análise das reservas, a
estimativa paramétrica e a reconciliação dos limites de financiamento.
E as saídas são a linha de base dos custos, as necessidades de financiamento do pro-
jeto, o plano de gerenciamento de custos (atualizações) e as mudanças solicitadas.

O planejamento da qualidade tem por objetivo identificar padrões de qualidade im-
portantes para o projeto e verificar como obter a satisfação desses padrões.
Devido à sua importância, este processo deve ser executado freqüentemente e em
paralelo com os outros processos de planejamento do projeto. O moderno gerencia-
mento da qualidade complementa o gerenciamento de projetos. Ambas as discipli-
nas reconhecem a importância de satisfação do cliente, prevenção sobre inspeção,
responsabilidade da gerência e melhoria contínua.


cessos organizacionais, a declaração do escopo do projeto e o plano de gerenciamen-
to do projeto.
As suas ferramentas e técnicas são a análise de custo-benefício, o benchmarking, o
projeto de experimentos, o custo da qualidade e as ferramentas adicionais de plane-
jamento da qualidade.
E as saídas são o plano de gerenciamento da qualidade, as métricas de qualidade, as
listas de verificação da qualidade, o plano de melhorias no processo, a linha de base
de qualidade e o plano de gerenciamento do projeto (atualizações).

O planejamento de recursos humanos envolve a identificação, documentação de
funções, responsabilidades e relações hierárquicas do projeto.
As entradas deste processo são os fatores ambientais da empresa (organizacional,
técnico, interpessoal, logístico e político), os ativos de processos organizacionais e o
plano de gerenciamento do projeto contendo os recursos necessários para a atividade.
As suas ferramentas e técnicas são o organograma e as descrições de cargos, o net-
working e a teoria organizacional.
E as saídas são as funções e as responsabilidades (função, autoridade, responsabili-
dade e competência), o organograma do projeto, o plano de gerenciamento de pes-
soal (recrutamento e seleção, tabela de horários, critérios de liberação, necessidade
de treinamento, reconhecimento e premiações).

O planejamento das comunicações tem como objetivo identificar e determinar quais
informações serão necessárias para o projeto e de que forma serão comunicadas en-
tre as partes envolvidas. Parte desse gerenciamento da comunicação pode também
ser realizada na fase inicial do projeto. Quanto mais cedo gerenciar essas informa-
ções e as comunicações, melhor.
to do projeto, incluindo as restrições e premissas.
As suas ferramentas e técnicas são a análise dos requisitos das comunicações e a
tecnologia das comunicações (fatores que podem afetar o projeto: a urgência da ne-
cessidade de informação, a disponibilidade de tecnologia, a formação de pessoa espe-
rada do projeto, a duração do projeto e o ambiente do projeto).
E a saída é o plano de gerenciamento das comunicações. Este plano deve conter
os requisitos de comunicações das partes interessadas, as informações que serão
comunicadas e em que formato, conteúdo e nível de detalhes, a pessoa responsável
pela comunicação das informações, a pessoa ou os grupos que receberão as infor-
mações, os métodos ou tecnologias usados para transmitir as informações, como

CAPÍTULO 6 171
e-mails e comunicados à imprensa, o método para atualizar e refinar o plano de ge-

renciamento das comunicações no decorrer do projeto e um glossário de termos
comumente utilizados.

O planejamento do gerenciamento de riscos é o processo de decidir como abordar,
planejar e executar as atividades de gerenciamento de riscos de um projeto.
to do projeto.
As suas ferramentas e técnicas são a análise de reuniões de planejamento. Utilize
um software de criação de mapas mentais para auxiliar neste processo.
E a sua saída é o plano de gerenciamento de riscos, que deve conter a metodologia,
as funções e responsabilidades, o orçamento, os tempos, as categorias de riscos, a de-
finição de probabilidade e o impacto dos riscos, a matriz de probabilidade e impacto,
a revisão das tolerâncias das partes interessadas, os formatos de relatórios e o acom-
panhamento.

A identificação dos riscos envolve determinar quais são os riscos que podem causar
impactos no projeto e, principalmente, documentar as características desses riscos.
O interessante é que todos os envolvidos participem do processo de identificação de
riscos, porque cada um deles tem uma visão diferente do que seja risco e onde ele
pode ocorrer no projeto. A participação de todos garante que “todos” os riscos sejam
identificados do ponto de vista individual. Depois de identificá-los individualmente,
junte tudo em um documento só.
Lembre-se de que a identificação dos riscos acontece de forma progressiva, ou
seja, à medida que o projeto vai se desenrolando, novos riscos vão surgindo, os quais
devem ser proativamente identificados e gerenciados.
A identificação dos riscos não é somente função do gerente de projetos, é função
de todos os envolvidos: cliente, membros da equipe do projeto, patrocinador, fornecedores, ge-
rente do projeto e quaisquer pessoas afetadas pelo projeto. Utilize um software de criação de
mapas mentais para auxiliar neste processo.
cessos organizacionais, a declaração do escopo do projeto, o plano de gerenciamento
de riscos e o plano de gerenciamento do projeto.
As suas ferramentas e técnicas são as revisões da documentação, as técnicas de coleta
de informações (brainstorming, técnica de Dephi, entrevistas, identificação da causa-raiz e
análise dos pontos fortes e fracos, das oportunidades e ameaças – SWOT), a análise da lis-
ta de verificação, a análise de premissas e as técnicas com diagramas (diagrama de causa e
efeito, diagramas do sistema ou fluxogramas, diagramas de influência).

E a saída é o registro de riscos, que deve conter uma lista de riscos identificados,
uma lista de respostas possíveis, as causas-raiz do risco e as categorias de risco atuali-
zadas.

A análise qualitativa dos riscos é o processo responsável por avaliar o impacto e a pro-
babilidade dos riscos identificados, permitindo determinar a importância de se tratar
riscos específicos e tomar ações proativas quando estes ocorrerem.
As entradas deste processo são os ativos de processos organizacionais (os dados so-
bre riscos de projetos passados e a base de conhecimento de lições aprendidas), a de-
claração do escopo do projeto, o plano de gerenciamento de riscos e o registro de ris-
cos com a lista de riscos identificados.
As suas ferramentas e técnicas são a avaliação de probabilidade e os impactos de
riscos, a matriz de probabilidade e impacto, a avaliação da qualidade dos dados sobre
riscos, a categorização de riscos e a avaliação da urgência do risco.
E as saídas são o registro de riscos (atualizações) que deve conter a classificação re-
lativa ou a lista de prioridades dos riscos do projeto, os riscos agrupados por cate-
gorias, a lista de riscos que exigem respostas a curto prazo, a lista de riscos para análi-
se e resposta adicionais, as listas de observação de riscos de baixa prioridade e as ten-
dências dos resultados da análise qualitativa de riscos.

A análise quantitativa dos riscos é o processo que tem como função analisar numeri-
camente e verificar a probabilidade de cada risco e seus impactos nos objetivos do
projeto.
As entradas deste processo são os ativos de processos organizacionais (os dados so-
bre riscos de projetos passados e a base de conhecimento de lições aprendidas), a de-
claração do escopo do projeto, o plano de gerenciamento de riscos, o registro de ris-
cos e o plano de gerenciamento do projeto com o plano de gerenciamento do crono-
grama do projeto e o plano de gerenciamento de custos do projeto.
As suas ferramentas e técnicas são as técnicas de representação e coletas de dados (en-
trevistas, distribuição de probabilidades e opinião especializada), a análise quantitativa de
riscos e técnicas de modelagem (análise de sensibilidade, análise de valor monetário es-
perado, análise da árvore de decisão) e a modelagem e simulação (Monte Carlo).
E a saída é o Registro de riscos (atualizações).

O planejamento de respostas a riscos é o processo que tem como função reduzir as
ameaças de riscos em relação às metas do projeto. Inclui a identificação de pessoas ou
grupos, e a eles são atribuídas as responsabilidades para assegurar que os riscos sejam
identificados e tratados corretamente, de forma proativa e organizada.

CAPÍTULO 6 173
As entradas deste processo são o plano de gerenciamento de riscos e o registro de

riscos.
As suas ferramentas e técnicas são as estratégias para riscos negativos ou ameaças
(prevenir, transferir e mitigar ), as estratégias para riscos positivos ou oportunidades
(explorar, compartilhar, melhorar), a estratégia para ameaças e oportunidades
(aceitação) e a estratégia para resposta contingenciais.
E as saídas são o registro de riscos (atualizações) que pode incluir os riscos identifi-
cados, suas descrições, áreas afetadas do projeto, suas causas e como eles podem afe-
tar os objetivos do projeto; os proprietários do risco e responsabilidades designadas;
as saídas dos processos de análise qualitativa e quantitativa de riscos; as estratégias
acordadas; as ações específicas para implementar a estratégia de resposta escolhida;
os sintomas e os sinais de alerta da ocorrência de risco; o orçamento e as atividades do
cronograma necessários para implementar as respostas escolhidas e as reservas de
contingências dos custos e de tempo projetadas para fornecer as tolerâncias a risco
das partes envolvidas – o plano de gerenciamento do projeto (atualizações) e os acor-
dos contratuais relacionados a riscos (seguros).

O planejamento das aquisições é o processo responsável por identificar quais neces-
sidades do projeto podem ser mais bem atendidas através da contratação de produtos
ou serviços externos à organização. Determina o que comprar ou adquirir e quando
e como fazer isso.
cessos organizacionais (diretrizes e políticas de contratação existente na empresa), a
declaração do escopo do projeto, a EAP, o dicionário da EAP e o plano de gerencia-
mento do projeto com o registro de riscos, os acordos contratuais, os recursos ne-
cessários para a atividade, o cronograma do projeto, as estimativas de custos da ativi-
dade e a linha de base dos custos.
As suas ferramentas e técnicas são a análise de fazer ou comprar, a opinião especia-
lizada e os tipos de contratos (Contratos de preço fixo ou preço global, Contratos de
custos reembolsáveis e Contratos por tempo e material).
E as saídas são o plano de gerenciamento de aquisições, a declaração do trabalho do con-
trato e as decisões de fazer ou comprar e as mudanças solicitadas. O plano de gerencia-
mento de aquisições deve conter os seguintes itens, mas não se limitar a eles: tipos de
contratos a serem usados, restrições, premissas, documentos de aquisição padronizados
e a métricas de aquisição a serem usadas para gerenciar contratos e avaliar fornecedores.
Planejamento de contratações (12.2)

O processo de planejar contratações tem a função de preparar os documentos neces-
sários para dar suporte ao processo Solicitar respostas de fornecedores e ao processo Sele-
cionar fornecedores.

As entradas deste processo são o plano de gerenciamento de aquisições, a declara-

ção do trabalho do contrato, o plano de gerenciamento do projeto com o registro dos
riscos, os acordos contratuais relacionados a riscos, os recursos necessários para a
atividade, o cronograma do projeto, as estimativas de custos da atividade e a linha de
base dos custos.
As suas ferramentas e técnicas são os formulários padrão que incluem contratos
padrão, as descrições padrão de itens de aquisição, os termos de confidencialidade,
as listas de verificação de critérios de avaliação de propostas ou as versões padroniza-
das de todas as partes dos documentos de licitação necessários.
E as saídas são: documentos de aquisição, critérios de avaliação (entendimento da
necessidade, custo total ou do ciclo de vida, capacidade técnica, abordagem de ge-
renciamento, abordagem técnica, capacidade financeira, interesse e capacidade de
produção, tamanho e tipo do negócio, referências, direitos de propriedade intelec-
tual e direitos de propriedade) e declaração do trabalho do contrato (atualizações).
CONCLUSÃO
Vimos como os processos de Planejamento são essenciais e relevantes para uma efetiva
condução dos projetos.
Você, como gerente do projeto, a sua equipe e todas as partes interessadas no pro-
jeto devem gastar boa parte do tempo planejando, sempre com um olho no peixe e o ou-
tro no gato!
No próximo capítulo veremos os processos de Execução.

CAPÍTULO 7
Processos de execução
INTRODUÇÃO
O grupo de processos de Execução é formado pelos processos usados para terminar o
trabalho determinado no plano de gerenciamento do projeto para cumprir os requi-
sitos do projeto.
Através do grupo de processos de Execução é possível também coordenar as pes-
soas e os recursos, integrar e realizar as atividades do projeto de acordo com o plane-
jado no plano de gerenciamento do projeto.
Os processos de Execução estão divididos da seguinte forma:

OS PROCESSOS DE EXECUÇÃO
Vejamos então as características principais do grupo de processos de Execução.


Este processo tem a função de exigir do gerente de projeto e de sua equipe várias
ações para executar o plano de gerenciamento do projeto a fim de realizar o trabalho
determinado na declaração do escopo do projeto.
Algumas dessas ações são: executar as atividades conforme o planejado; alocar os
recursos financeiros necessários para realizar os objetivos do projeto; formar, trei-
nar e gerenciar os membros da equipe do projeto; obter as cotações, as licitações, as
ofertas ou as propostas conforme adequado; selecionar os fornecedores; obter, ge-
renciar e usar recursos, inclusive materiais, ferramentas, equipamentos e instalações
de forma eficaz; implementar as normas e os métodos planejados; criar, controlar,
verificar e validar as entregas do projeto; gerenciar os riscos e implementar as ativi-
dades de respostas a riscos; gerenciar os fornecedores e todas as interfaces do proje-
to; adaptar as mudanças aprovadas ao escopo; estabelecer e gerenciar os canais de co-
municação do projeto, tanto externos como internos à equipe do projeto; coletar
dados do projeto e relar custo, cronograma, progresso técnico e da qualidade e in-
formações sobre o andamento do projeto para facilitar a previsão e coletar e docu-
mentar as lições aprendidas e implementar as atividades de melhorias nos processos
aprovados.
As entradas deste processo são o plano de gerenciamento do projeto, as ações cor-
retivas aprovadas, as ações preventivas aprovadas, as solicitações de mudança apro-
vadas, o reparo de defeito aprovado, o reparo de defeito validado e o procedimento
de encerramento administrativo.
As suas ferramentas e técnicas são a metodologia de gerenciamento de projetos
(que define o processo que ajuda uma equipe de projetos na execução do plano do
projeto) e o sistema de informações do gerenciamento de projetos, que é um sistema
automatizado usado pela equipe de gerenciamento de projetos para ajudar na execu-
ção das atividades planejadas no plano de gerenciamento do projeto.
E as saídas são as entregas (qualquer produto ou resultado verificável identifica-
do na documentação do plano de gerenciamento do projeto, e que devem ser pro-
duzidos e fornecidos para terminar o projeto), as mudanças solicitadas, as solicita-
ções de mudanças implementadas, as ações corretivas e as preventivas implemen-
tadas, o reparo de defeito implementado e as informações sobre o desempenho do
trabalho (progresso do cronograma mostrando as informações sobre o andamen-
to, entregas terminadas e não terminadas, atividades do cronograma que foram
iniciadas e as que foram terminadas, até que ponto dos padrões de qualidade estão
sendo atendidos, custos autorizados e incorridos, estimativas para terminar as ati-
vidades do cronograma que foram iniciadas, percentual fisicamente terminado das
atividades do cronograma em andamento, as lições aprendidas documentadas co-
locadas na base de conhecimento de lições aprendidas e os detalhes de utilização
dos recursos.

PROCESSOS DE EXECUÇÃO
CAPÍTULO 7 177

A garantia da qualidade é a aplicação de atividades de qualidade planejadas e sistemá-
ticas para assegurar que o projeto irá empregar todos os processos necessários para
atender aos requisitos.
As entradas deste processo são o plano de gerenciamento da qualidade, as métri-
cas de qualidade, o plano de melhoria de processo, as informações sobre o desempe-
nho do trabalho, as solicitações de mudanças, as medições de controle da qualidade,
as solicitações de mudança implementadas, as ações corretivas implementadas, o re-
paro de defeito implementado e as ações preventivas implementadas.
As suas ferramentas e técnicas são as ferramentas e técnicas de planejamento de
qualidade, auditoria de qualidade, análise de processo, ferramentas e técnicas de
controle da qualidade.
E as saídas são as mudanças solicitas, as ações corretivas recomendadas, os ativos
de processo organizacionais (atualizações) e o plano de gerenciamento do projeto
(atualizações).

É o processo de obtenção das pessoas devidamente capacitadas para terminar o
projeto.
As entradas deste processo são os fatores ambientais da empresa (disponibilidade,
capacidade, experiência, interesse e custo), os ativos de processos organizacionais
(políticas e diretrizes de recrutamento de pessoal), as funções e responsabilidades,
os organogramas do projeto e o plano de gerenciamento de pessoal.
As suas ferramentas e técnicas são a pré-designação, a negociação, a contratação
ou mobilização e as equipes virtuais (comumente utilizadas em projetos de TI).
E as saídas são a designação de pessoal para o projeto, a disponibilidade de recursos
e o plano de gerenciamento de pessoal (atualizações).

O desenvolvimento da equipe do projeto possibilita o aumento da capacidade das
partes envolvidas em contribuir individualmente, bem como o aumento da capaci-
dade da equipe de funcionar como um time.
O crescimento individual (gerencial e técnico) é a base necessária para desenvol-
ver a equipe. O desenvolvimento como equipe é crucial para o projeto atingir seus
objetivos. O desenvolvimento da equipe num projeto é particularmente complicado
quando os membros se reportam ao gerente funcional e ao gerente de projeto (veri-
fique as estruturas organizacionais no Capítulo 2). O gerenciamento efetivo desse
duplo relacionamento de reporte é, normalmente, um fator crítico de sucesso para o
projeto e, geralmente, é responsabilidade do gerente do projeto.
Embora o desenvolvimento da equipe do projeto seja apresentado aqui como um dos
processos de execução, ele vai se desenvolvendo durante todo o ciclo de vida do projeto.

As entradas deste processo são a designação de pessoal para o projeto, o plano de

gerenciamento de pessoal e a disponibilidade de recursos.
As suas ferramentas e técnicas são as habilidades de gerenciamento geral (empatia,
influência, criatividade e facilitação de grupos), o treinamento (para aprimorar as
competências dos membros da equipe do projeto), atividades de formação de equi-
pe, as regas básicas, o agrupamento (todos no mesmo local físico para aprimorar a ca-
pacidade de trabalhar em equipe), o reconhecimento e as premiações (devem-se
considerar as diferenças culturais).
E a saída é a avaliação do desempenho da equipe. A avaliação da eficácia de uma
equipe pode incluir indicadores como as melhorias nas habilidades que permitem
que o pessoal realize as tarefas de modo mais eficaz, melhoria nas competências e nos
sentimentos que ajudam a equipe a atuar melhor como grupo (sinergia) e a taxa de
rotatividade de pessoal reduzida.

A distribuição das informações envolve a disponibilização de informações necessá-
rias a todos os envolvidos do projeto no momento oportuno.
A entrada deste processo é o plano de gerenciamento das comunicações.
As suas ferramentas e técnicas são as habilidades de comunicação (dimensões: es-
crita, oral, ouvir e falar, interna, externa, formal, informal, vertical e horizontal), o
sistema de coleta e recuperação de informações, os métodos de distribuição das in-
formações (reuniões de projetos através de atas, e-mails, telefone, fax, videoconfe-
rência, publicações na Internet e ferramentas eletrônicas de gerenciamento de pro-
jetos) e o processo de lições aprendidas (identificação e documentação do que deu cer-
to e principalmente do que deu errado no projeto para serem acessadas e utilizadas
como referência em projetos futuros).
E as saídas são os ativos de processos organizacionais (atualizações: documentação
das lições aprendidas, registros do projeto, relatório do projeto, apresentações do
projeto, feedback das partes interessadas e notificações das partes interessadas) e as
mudanças solicitadas.

A solicitação de respostas de fornecedores envolve a obtenção de informações, como
cotações e propostas dos fornecedores potenciais para o atendimento das necessi-
dades do projeto. A maioria do esforço real deste processo é despendida pelos po-
tenciais fornecedores, sem custo para o projeto.
As entradas deste processo são os ativos de processo organizacionais (listas de forne-
cedores pré-qualificados com informações sobre experiências passadas relevantes para
o projeto), o plano de gerenciamento de aquisições e os documentos de aquisição.
As suas ferramentas e técnicas são as reuniões com licitantes, os anúncios e o de-
senvolvimento da lista de fornecedores qualificados.

PROCESSOS DE EXECUÇÃO
CAPÍTULO 7 179
E as saídas são a lista de fornecedores qualificados, o pacote de documentos de

aquisição e as propostas (documentação preparada pelos fornecedores descrevendo
a capacidade de execução dos serviços para terminar o projeto).

A seleção de fornecedores envolve a recepção de coletas de preços ou propostas e a
aplicação dos critérios da organização para avaliação de fornecedores.
Os seguintes fatores podem ser avaliados no processo de seleção dos fornecedores
mais adequados para execução do projeto: preço ou custo (menor preço), aborda-
gem técnica (melhor tecnologia ou solução).
As entradas deste processo são os ativos de processos organizacionais (políticas de
avaliação de propostas), o plano de gerenciamento de aquisições, os critérios de ava-
liação (exemplos de produtos, amostras, experiência passada através de estudos de
casos de sucessos implementados em outros clientes), o pacote de documentos de
aquisição, as propostas, a lista de fornecedores qualificados (vendor list), o plano de
gerenciamento do projeto contendo o registro de riscos e os acordos contratuais re-
lacionados a riscos.
As suas ferramentas e técnicas são o sistema de ponderação, estimativas indepen-
dentes, sistema de triagem, negociação do contrato, sistemas de classificação de for-
necedores, opinião especializada, técnicas de avaliação de proposta.
E as saídas são os fornecedores selecionados, o contrato, o plano de gerenciamen-
to de contratos, a disponibilidade de recursos, o plano de gerenciamento de aquisi-
ções (atualizações) e as mudanças solicitadas.
CONCLUSÃO
A fase de Execução do projeto é aquela em que se gasta mais energia, tanto do gerente
do projeto quanto da equipe.
O gerente de projeto deve estar bem atento aos níveis de baixa produtividade e
funcionar como um elo de comunicação efetiva entre a equipe do projeto e o cliente.
Quando o gerente de projetos perceber baixos níveis de produtividade deve inte-
ragir de forma proativa com os recursos e perguntar-lhes o que é necessário para su-
perar as dificuldades, ajudando-os no desenvolvimento de suas atividades.
Os recursos devem ter a total liberdade de reportarem aos gerentes suas dificulda-
des para, em conjunto, tentarem resolvê-las.
Esse aspecto pode ser discutido nas primeiras reuniões gerenciais com a equipe do
projeto. Saber dosar essa energia através dos processos de Execução é um fator de su-
cesso para o projeto.
No próximo capítulo veremos o grupo de processos de Monitoramento e Controle do
projeto.
Te encontro lá!

CAPÍTULO 8
Processos de
monitoramento e controle
INTRODUÇÃO
Os processos de controle têm como função garantir que os objetivos do projeto se-
jam alcançados pela monitoração e mensuração de seu progresso, tomando ações
corretivas e proativas sempre que houver necessidade.
PROCESSOS DE MONITORAMENTO E CONTROLE

Os processos de monitoramento e controle são:
Monitoramento e controle de riscos (11.6)
Vejamos, então, suas características.


Este processo é realizado para monitorar os processos do projeto associados com a
iniciação, o planejamento, a execução e o encerramento. São tomadas as ações pre-
ventivas ou corretivas para controlar o desempenho do projeto. É importante que
seja feito um monitoramento contínuo no decorrer do projeto para verificar quais
áreas merecem maior atenção para não correr os riscos de tirar o projeto dos trilhos.
Comparação é uma palavra-chave neste processo, pois é possível comparar o desem-
penho real do projeto com o plano de gerenciamento do projeto.
As entradas deste processo são o plano de gerenciamento do projeto, as informa-
ções sobre o desempenho do trabalho e as solicitações de mudanças rejeitadas.
As suas ferramentas são a metodologia de gerenciamento de projetos, o sistema de
informações do gerenciamento de projetos, a técnica de valor agregado e a opinião
especializada.
E as saídas são as ações corretivas recomendadas, as ações preventivas recomenda-
das, as previsões, o reparo de defeito recomendado e as mudanças solicitadas.

O controle integrado de mudanças se preocupa em influenciar os motivos geradores
das mudanças para garantir que elas sejam acordadas; determinar a ocorrência de
uma mudança e gerenciar as mudanças no momento em que elas ocorrem. Este pro-
cesso deve ser realizado desde o início do projeto até o seu término.
O controle integrado de mudanças requer manter a integridade das métricas bási-
cas de desempenho; assegurar que as mudanças no escopo do produto estejam refle-
tidas na definição no escopo do projeto; e coordenar as mudanças entre as áreas de
conhecimento.
As entradas deste processo são o plano de gerenciamento do projeto, as mudanças
solicitadas, as informações sobre o desempenho do trabalho, as ações preventivas re-
comendadas, o reparo de defeito recomendado e as entregas.
sistema de informações do gerenciamento de projetos e a opinião especializada.
E as saídas são as solicitações de mudanças aprovadas, as solicitações de mudanças
rejeitadas, o plano de gerenciamento do projeto (atualizações), a declaração do esco-
po do projeto (atualizações), as ações corretivas aprovadas, as ações preventivas
aprovadas, o reparo de defeito aprovado e as entregas.

A verificação do escopo é o processo de formalização do aceite do escopo do projeto
por todos os envolvidos (patrocinador, cliente, usuário, empresa executora, entre
outros). Neste processo é feita uma revisão dos produtos e resultados do trabalho
para assegurar que tudo foi realizado de forma completa e satisfatória.

CAPÍTULO 8 183
As entradas deste processo são a declaração do escopo do projeto, o dicionário da

EAP, o plano de gerenciamento do escopo do projeto e as entregas.
As suas ferramentas e técnicas são a inspeção, que inclui atividades como medição,
exame e verificação para determinar se o trabalho e as entregas atendem aos requisi-
tos e aos critérios de aceitação do produto.
E as saídas são as entregas aceitas, as mudanças solicitadas e as ações corretivas re-
comendadas.

O processo de controle do escopo tem como objetivos verificar os fatores que criam
mudanças no escopo para assegurar que essas mudanças sejam analisadas, discutidas
e acordadas antes da implementação; além de determinar quando houve uma mu-
dança no escopo e gerenciar as mudanças no momento em que ocorrerem. O con-
trole das mudanças do escopo deve se integrar aos demais processos de controle.
As entradas deste processo são a declaração do escopo do projeto, a EAP, o dicio-
nário da EAP, o plano de gerenciamento do escopo do projeto, relatório de desem-
penho, as solicitações de mudanças aprovadas e as informações sobre o desempenho
do trabalho.
As suas ferramentas e técnicas são o sistema de controle de mudanças (formaliza a
mudança através de documentação e assinaturas), a análise de variação, o replaneja-
mento e o sistema de gerenciamento de configuração, que fornecem procedimentos
para obtenção da situação das entregas e garante que as mudanças solicitadas no esco-
po do projeto e no escopo do produto sejam cuidadosamente consideradas e docu-
mentadas, antes de serem processadas pelo Controle integrado de mudanças.
E as saídas são a declaração do escopo do projeto (atualizações), a EAP (atualiza-
ções) e o dicionário da EAP (atualizações), a linha de base do escopo (atualizações),
as mudanças solicitadas, as ações corretivas recomendadas, os ativos de processos or-
ganizacionais (atualizações) e o plano de gerenciamento do projeto (atualizações).

O controle do cronograma tem como objetivos assegurar que os aspectos geradores
das mudanças sejam benéficos para a condução do projeto, além de propiciar o ge-
renciamento das mudanças reais no momento em que elas acontecerem.
As entradas deste processo são o plano de gerenciamento do cronograma, a linha
de base do cronograma, o relatório de desempenho e as solicitações de mudanças.
As suas ferramentas e técnicas são o relatório de progresso (incluem informações
como as datas de início e de término reais e as durações restantes das atividades do
cronograma não terminadas), o sistema de controle de mudanças de cronograma, a
medição de desempenho, o software de gerenciamento de projetos, a análise de va-
riação e os gráficos de barras de comparação do cronograma.

E as saídas são os dados de modelo de cronograma (atualizações), a linha de base

do cronograma (atualizações), as medições de desempenho, as mudanças solicitadas,
as ações corretivas recomendadas e os ativos de processos organizacionais (atualiza-
ções), a lista de atividades (atualizações), os atributos da atividade (atualizações) e o
plano de gerenciamento do projeto (atualizações).

O controle de custos tem como função verificar os fatores que criam as mudanças no
baseline de custo de forma a garantir que essas mudanças sejam benéficas para a con-
dução do projeto, além de gerenciar as mudanças reais quando e no contexto em que
surgirem.
As entradas deste processo são a linha de base dos custos, as necessidades de finan-
ciamento do projeto, o relatório de desempenho, as informações sobre o desempe-
nho do trabalho (entregas terminadas e ainda não terminadas, os custos autorizados e
incorridos, as estimativas para terminar as atividades do cronograma e percentual fi-
sicamente terminado das atividades do cronograma), as solicitações de mudança
aprovadas e o plano de mudança aprovadas.
As suas ferramentas são o sistema de controle de mudança nos custos, análise de
medição de desempenho (valor planejado, valor agregado, custo real, estimativa
para terminar e estimativa ao término, variação de custo, variação de prazos e índice
de desempenho de custos, índice de desempenho de custos cumulativo e índice de
desempenho de prazos), previsão, análise de desempenho do projeto (análise da va-
riação, análise das tendências e tendência do valor agregado), software de gerencia-
mento de projetos, e gerenciamento das variações.
E as saídas deste processo são as estimativas de custos (atualizações), a linha de
base dos custos (atualizações), a previsão de término, as mudanças solicitadas, as
ações corretivas recomendadas, os ativos de processos organizacionais (atualizações)
e o plano de gerenciamento do projeto (atualizações).

O processo de realizar o controle da qualidade envolve monitorar os resultados es-
pecíficos do projeto para determinar se eles estão de acordo com os padrões de qua-
lidade esperados e identificar formas de eliminar as causas dos resultados insatisfa-
tórios. É importante que este processo seja executado ao longo de todo o ciclo de
vida do projeto.
As entradas deste processo são o plano de gerenciamento da qualidade, as métri-
cas de qualidade, as listas de verificação da qualidade e as informações sobre o desem-
penho do trabalho.
As suas ferramentas e técnicas são o diagrama de causa e efeito, os gráficos de con-
trole, a elaboração de fluxogramas, o histograma, o diagrama de Pareto, o gráfico de
execução, o diagrama de dispersão, as amostragens estatísticas, a inspeção e revisão

CAPÍTULO 8 185
do reparo de defeito. O diagrama de Pareto “é um histograma, ordenado por fre-

qüência de ocorrência, que mostra quantos resultados foram gerados por tipo ou ca-
tegoria de causa identificada”. A ordenação por freqüência é utilizada para direcionar
as ações corretivas – a equipe do projeto deve tomar ações para corrigir, primeira-
mente, os problemas que estão causando a maior quantidade de defeitos. Os diagra-
mas de Pareto estão, conceitualmente, relacionados à Lei de Pareto, que afirma que
“uma quantidade consideravelmente pequena de causas normalmente produzirá a
maioria dos problemas ou defeitos. Ela é comumente referenciada como princípio
de 80/20, em que 80% dos problemas se devem a 20% das causas”.
E as saídas são medições de controle da qualidade, reparo de defeito validado, li-
nha de base da quantidade (atualizações), ações corretivas recomendadas, ações pre-
ventivas recomendadas, mudanças solicitadas, reparo de defeito recomendado, ati-
vos de processos organizacionais (atualizações), entregas validadas e o plano de ge-
renciamento do projeto (atualizações).

O processo de gerenciar a equipe do projeto envolve o acompanhamento do desempe-
nho dos integrantes da equipe do projeto, o fornecimento de feedback, a resolução de
problemas e a coordenação de mudanças para melhorar o desempenho do projeto.
As entradas deste processo são os ativos de processos organizacionais (políticas e
diretrizes para premiação dos integrantes da equipe durante o decorrer do proje-
to), a designação de pessoal para o projeto, as funções e responsabilidades, os orga-
nogramas do projeto, o plano de gerenciamento de pessoal, a avaliação do desem-
penho da equipe, as informações sobre o desempenho do projeto e os relatórios
de desempenho.
As suas ferramentas e técnicas são as observações e conversas, as avaliações de de-
sempenho do projeto, o gerenciamento de conflitos (se bem-sucedido resulta em
maior produtividade) e o registro de problemas (ajuda a equipe do projeto a monito-
rar os problemas até o encerramento).
E as saídas deste processo são as mudanças solicitadas, as ações corretivas recomen-
dadas, as ações preventivas recomendadas e os ativos de processos organizacionais
(atualizações: entradas para avaliações de desempenho organizacional e documentação
das lições aprendidas) e o plano de gerenciamento do projeto (atualizações).

O relatório de desempenho envolve colher e disseminar as informações de desempe-
nho para posicionar todos os envolvidos sobre a utilização dos recursos no sentido de
atingir os objetivos do projeto. O processo de relato de desempenho inclui:
Relatórios de status – descrevem a posição atual do projeto. Exemplo: status

com relação ao cronograma e ao orçamento.

Relatórios de progresso – descrevem o que a equipe do projeto já conseguiu

realizar. Exemplo: percentual das atividades completadas versus as atividades
em andamento.
Previsões – prognosticam o futuro do projeto em termos de situação atual e an-
damento.
O relato de desempenho provê informações sobre o escopo, o prazo, o custo e a

qualidade, os riscos e as contratações. Os relatórios podem ser preparados de forma
resumida ou analítica.
As entradas deste processo são as informações sobre o desempenho do trabalho, as
medições de desempenho, a previsão de término, as medições de controle da quali-
dade, o plano de gerenciamento do projeto com a linha de base da medição de de-
sempenho, as solicitações de mudanças aprovadas e as entregas.
As suas ferramentas e técnicas são as ferramentas de apresentação de informa-
ções, a coleta e compilação das informações sobre o desempenho, as reuniões de
avaliação do andamento, os sistemas de relatórios de horas e os sistemas de relató-
rios de custos.
E as saídas são os relatórios de desempenho, as previsões, as mudanças solicita-
das, as ações corretivas recomendadas e os ativos de processos organizacionais
(atualizações).

Este processo envolve o gerenciamento das comunicações para atender às necessidades
das partes interessadas no projeto e resolver problemas com elas. Isso aumenta as chan-
ces de o projeto não se desviar dos trilhos por causa de problemas não resolvidos.
As entradas deste processo são o plano de gerenciamento das comunicações e os
ativos de processos organizacionais.
As suas ferramentas e técnicas são os métodos de comunicação (reuniões presen-
ciais) e o registro de problemas.
E as saídas são os problemas resolvidos, as solicitações de mudança aprovadas, as
ações corretivas aprovadas, os ativos de processo organizacionais (atualizações) e o
plano de gerenciamento do projeto (atualizações).
Monitoramento e Controle de riscos (11.6)

O monitoramento e controle de riscos é o processo de manter a rastreabilidade dos
riscos identificados, monitorar riscos residuais e identificar novos riscos, assegurar a
execução dos planos de risco e avaliar a sua efetividade na redução dos riscos. O mo-
nitoramento e o controle de riscos registra as métricas de riscos que são associadas à
implementação dos planos de contingência. O controle e monitoração de riscos é
um processo contínuo para a vida do projeto. Os riscos mudam quando o projeto
amadurece, novos riscos surgem ou riscos previstos desaparecem.

CAPÍTULO 8 187
As entradas deste processo são o plano de gerenciamento de riscos, o registro dos

riscos, as solicitações de mudanças aprovadas, as informações sobre o desempenho
do trabalho e os relatórios de desempenho.
As suas ferramentas e técnicas são a reavaliação de riscos, a auditoria de riscos, a
análise das tendências e da variação, a medição do desempenho técnico, a análise das
reservas e as reuniões de andamento.
E as saídas são os registros dos riscos (atualizações), as mudanças solicitadas, as
ações corretivas recomendadas, as ações preventivas recomendadas, os ativos de
processos organizacionais (atualizações) e o plano de gerenciamento do projeto
(atualizações)

Este processo garante que o desempenho do fornecedor atenda aos requisitos con-
tratuais e que o comprador atue de acordo com os termos do contrato. O processo
de administração de contrato também possui um componente de gestão financeira
que envolve o monitoramento de pagamentos ao fornecedor e analisa e documenta a
qualidade do desempenho atual ou passado de um fornecedor com base no contrato e
nas ações corretivas estabelecidas.
As entradas deste processo são o contrato, o plano de gerenciamento de contra-
tos, a seleção de fornecedores, os relatórios de desempenho, as solicitações de mu-
dança aprovadas e as informações sobre o desempenho do trabalho.
As suas ferramentas e técnicas são o sistema de controle de mudanças no contrato,
a análise de desempenho conduzido pelo comprador, as inspeções e auditorias, o re-
latório de desempenho, o sistema de pagamentos, a administração de reclamações, o
sistema de gerenciamento de registros e tecnologia da informação.
E as saídas são a documentação do contrato, as mudanças solicitadas, as ações corre-
tivas recomendadas, os ativos de processos organizacionais (atualizações: correspon-
dência, cronogramas e solicitações de pagamentos e documentação de avaliação de de-
sempenho do fornecedor) e o plano de gerenciamento do projeto (atualizações).
CONCLUSÃO
Vimos como os processos de controle do projeto são importantes para a condução do
projeto.
Nesta fase o gerente de projeto também gasta boa parte da sua energia. Saber do-
sar as energias desprendidas nas fases de execução e de controle é um fator de sucesso
para o efetivo gerenciamento do projeto.
No próximo capítulo veremos os processos da última fase do ciclo de vida do pro-
jeto, o encerramento.

CAPÍTULO 9
Processos de encerramento
INTRODUÇÃO
Os processos de encerramento têm como objetivo formalizar a aceitação do projeto
como um todo ou a finalização de uma fase do projeto, e devem ser conduzidos de
forma organizada.
PROCESSOS DE ENCERRAMENTO
Este grupo de processos contém apenas dois processos:


Este processo envolve a realização da parte de encerramento do projeto do plano de
gerenciamento do projeto. Ele encerra a parte do escopo do projeto e as atividades
associadas, aplicáveis a uma determinada fase. Dois procedimentos são desenvolvi-
dos a fim de estabelecer as interações necessárias para realizar as atividades de encer-
ramento em todo projeto ou em uma fase do projeto: procedimento de encerramen-
to administrativo e procedimento de encerramento de contratos.
As entradas deste processo são o plano de gerenciamento do projeto, a documen-
tação do contrato, os fatores ambientais da empresa, os ativos de processos organiza-
cionais, as informações sobre o desempenho do trabalho e as entregas.


sistema de informações do gerenciamento de projetos e a opinião especializada.
E as saídas são o procedimento de encerramento administrativo, o procedimento de
encerramento de contratos, o produto, o serviço ou resultado final e os ativos de pro-
cessos organizacionais (atualizações: documentação da aceitação formal, arquivos do
projeto, documentos de encerramento do projeto e as informações históricas).

O processo encerramento do contrato dá apoio ao processo para encerrar o projeto,
pois envolve a confirmação de que todo trabalho e as entregas foram aceitas pelo
cliente ou usuário no caso de projetos de TI.
As entradas deste processo são o plano de gerenciamento de aquisições, o plano de
gerenciamento de contratos, a documentação do contrato e o procedimento de en-
cerramento de contratos.
As suas ferramentas e técnicas são a auditoria de aquisição e o sistema de gerencia-
mento de registros.
E as saídas são os contratos encerrados e os ativos de processos organizacionais
(atualizações: arquivo do contrato, aceitação da entrega e a documentação das lições
aprendidas).
CONCLUSÃO
Vimos brevemente, nos Capítulos 5, 6, 7, 8 e 9, que os processos das melhores práti-
cas de gerenciamento de projetos do PMI, organizados no PMBOK – Terceira Edição,
podem (e devem) ser aplicados à gestão de projetos de tecnologia da informação.
No PMBOK – Terceira Edição, estes processos foram bem estruturados e inseridos
no contexto das áreas do conhecimento: gerenciamento da integração, escopo, tem-
po, custos, qualidade, recursos humanos, comunicações, riscos e aquisições. Neste
livro, apresentei os processos de gerenciamento de projetos através de uma aborda-
gem cronológica, agrupados nas fases de Iniciação, Planejamento, Execução, Monitora-
mento e controle e Encerramento.
Bons frutos têm sido colhidos pelas organizações que estão adotando as melhores
práticas de gerenciamento de projetos do PMI, publicadas no PMBOK – Terceira Edição.
Para reforçar aconselho a leitura do livro Selling Project Management to Senior Executi-
ves: Framing the Moves that Matter, dos autores Janice Thomas, PhD; Connie Delisle,
PhD; e Kam Jugdev, PhD Candidate, PMP. Nesta publicação do PMI você vai apren-
der como “vender o peixe” do gerenciamento de projetos para os executivos seniores
da sua empresa. Para mais informações, acesse o link: http://www.pmibookstore.org

PA R TE I I I
A profissão gerente
de projetos

CONSIDERAÇÕES
A terceira parte deste livro é inteiramente dedicada ao gerente de projetos como pro-
fissão. Veremos sua importância para o mundo dos negócios, seu crescimento e reco-
nhecimento internacional.
No Capítulo 10, abordarei algumas associações profissionais e suas certificações
para os gerentes de projetos. Para cada associação profissional teremos um breve re-
sumo institucional e seus programas de certificações, bem como as informações dos
Web sites de cada associação.
Logo em seguida, no Capítulo 11, apresentarei ao gerente de projetos alguns
exemplos interessantes de software para auxiliá-lo na automatização de tarefas e na
sua empreitada diária. Alguns desses aplicativos estão sendo apresentados pela pri-
meira vez para a Comunidade Brasileira de TI.
No Capítulo 12 você poderá utilizar as informações fornecidas para analisar, justi-
ficar e promover a execução de novos projetos de TI na sua organização. Mas, antes,
vejamos um breve panorama atual sobre a profissão gerente de projetos.
A PROFISSÃO GERENTE DE PROJETOS

Conforme prefaciado por Vargas, as mudanças são constantes e inerentes em nossas
vidas e no mundo dos negócios. Com a sua devida permissão, Ricardo, gostaria de fa-
zer um pequeno adendo às suas observações, dizendo que essas mudanças são ainda
mais críticas e rápidas para as organizações que lidam e/ou dependem de projetos de
tecnologia da informação para sobreviverem.
Exemplificando, o mundo passou por uma grande mudança com a qual todos tive-
mos menores ou maiores doses de preocupações: o “bug do milênio”. Resolver esse
“problema” no final da década de 1990 foi uma das prioridades dos departamentos de
tecnologia da informação das organizações.
A partir do ano 2000, presenciamos mais algumas mudanças no cenário de projetos de
tecnologia da informação e na evolução da tecnologia como um todo. Houve uma cres-
cente demanda por projetos de desenvolvimento de aplicações Web (a maioria fomenta-
da pelo desenvolvimento de Web sites ou portais corporativos para a área financeira –
bancos privados e do governo; hoje não consigo me imaginar enfrentando uma fila de
banco, perdendo um precioso tempo, para pagar uma conta, se posso realizar com segu-
rança e em menos de alguns minutos, essa mesma transação pela Internet); projetos en-
volvendo novas tecnologias de telecomunicações; projetos de infra-estrutura (abordados
no Capítulo 12); projetos de Business Inteligence, Data Warehouse, entre outros.
Com essas demandas, surgiu também a necessidade de as organizações adotarem
padrões de gerenciamento de projetos mais rigorosos, com o objetivo de garantir o
sucesso e o menor tempo de implementação dos projetos, já que o fator tempo em TI
é o que manda e desmanda!
Graças a essas mudanças e a outras que ainda virão pela frente (propiciando o am-
biente perfeito para o gerenciamento de projetos: as incertezas), a profissão de ge-

A PROFISSÃO GERENTE DE PROJETOS
PARTE III 193
rente de projetos está crescendo a passos largos e sendo cada vez mais necessária, so-
licitada e reconhecida nas organizações do mundo inteiro.
Não consigo enxergar o mundo globalizado dos negócios sem passar pela engrena-
gem lubrificada dos projetos e pela inspeção campeã das práticas de gerenciamento
de projetos.
A revista Fortune publicou um artigo intitulado Planning Carrer in a World Without
Managers, em que os autores Thomas A. Stewart e Joe McGowan chamavam a profis-
são gerente de projetos como a escolha de carreira número um.
Um relatório do Project Management Institute realizado no ano de 2000, intitulado
PMI’s 2000 Salary Survey, estimou que a média anual de salário de um gerente de pro-
jetos nos Estados Unidos era de US$81.000.
Nos anos 90, muitas organizações começaram a implementar escritórios de projetos
para adquirir expertise em gerenciamento de projetos e para criar maiores condições
de desenvolvimento da carreira de gerente de projetos.
Graças a esse crescimento, encontramos no Brasil várias universidades federais,
privadas, sem fins lucrativos, todas reconhecidas pelo MEC, que oferecem cursos de
pós-graduação (lato e strictu sensu), MBAs de gerenciamento de projetos ou cursos
mais genéricos e/ou específicos que contenham matérias de gerenciamento de pro-
jetos. A maioria dessas instituições também firma convênios com universidades nos
Estados Unidos e em outros países para o reconhecimento internacional do curso e
do certificado. Vale a pena conferir e investir.
No Brasil temos a ABGP (Associação Brasileira de Gerenciamento de Projetos) e
os Capítulos Regionais do PMI (Project Management Institute), os quais fornecem
todo apoio necessário para os membros recém-associados, fomentando diversos
eventos de gerenciamento de projetos tais como congressos, treinamentos, seminá-
rios, workshops, palestras. A lista dos eventos é infindável. Nunca se falou tanto em
gerenciamento de projetos como nestes últimos anos.
E não pára por aí! Os grupos editoriais brasileiros estão publicando excelentes li-
vros sobre o assunto gerenciamento de projetos. Bibliografia é o que não falta. Para
mim seria uma grande honra que este livro fizesse parte da sua biblioteca!
Para atender às demandas e acompanhar as constantes mudanças do mundo da tec-
nologia da informação, o gerente de projetos deve manter-se atualizado sobre as me-
todologias e melhores práticas propostas pelas associações profissionais e continuar a
desenvolver e fomentar a sua profissão através da realização de cursos, participações
em seminários e congressos. Ele também deve pesquisar e criar o hábito prazeroso da
leitura de livros especializados (nacionais e importados), fomentar as melhores prá-
ticas de gerenciamento de projetos na organização e nos projetos e participar de
eventos nacionais e internacionais promovidos pelas associações profissionais e por
outras instituições/organizações, além de procurar manter sempre em dia as suas
certificações junto às associações profissionais, buscando evolução constante de seu
conhecimento e habilidades profissionais.

Vale a pena lembrar também da ética profissional, que é importante para todas as
profissões. As associações profissionais desenvolveram códigos de ética para os pro-
fissionais de gerenciamento de projetos, que deverão ter as seguintes condutas: man-
ter altos padrões de integridade e conduta profissional; responsabilizar-se por suas
ações; buscar continuamente o aperfeiçoamento das habilidades profissionais; prati-
car a profissão com lealdade e honestidade e encorajar outras pessoas no engajamen-
to da profissão para agirem de maneira profissional e com ética.
Por tudo isso, não me arrisco ao dizer que o terreno para profissão gerente de pro-
jetos está mais do que adubado. Portanto, só resta agora você lançar as sementes da
vontade e da dedicação, com o objetivo de criar raízes de conhecimentos, experi-
mentar o sucesso das práticas das associações profissionais, crescer profissionalmen-
te e colher bon$ fruto$.
Vejamos então um pouco sobre as associações profissionais, que, juntamente com
os seus membros associados, suas melhores práticas e seus representantes regionais,
pegarão em sua mão e irão ajudá-lo a caminhar pela estrada do presente e do futuro
do gerenciamento de projetos.
“Vem comigo!”

CAPÍTULO 10
Associações e certificações
profissionais para o
gerente de projetos
Neste capítulo veremos algumas associações profissionais de cunho nacional e inter-

nacional que fornecem vários recursos e benefícios para os seus associados, sejam
eles profissionais da área de TI, gerentes de projetos ou pessoas que estejam envolvi-
das com administração de empresas.
São instituições sem fins lucrativos responsáveis pela fomentação das melhores
práticas em suas especialidades e de uma maior integração de seus associados nos paí-
ses de origem e em outros países.
As associações abordadas neste capítulo são:
PMI – Project Management Institute

ABGP – Associação Brasileira de Gerenciamento de Projetos
AACE – The Association for the Advancement of Cost Engeneering
ISACA – Information Systems Audit and Control Association
PRMIA – The Professional Risk Managers’ International Association
IEEE Computer Society
ASQ – America Society for Quality
SHRM – Society for Human Resource Management
COMPTIA – Computer Technology Industry Association

PMI – PROJECT MANAGEMENT INSTITUTE

Introdução
Neste capítulo veremos um pouco sobre a Instituição que mais cresce e apóia a pro-
fissão gerente de projetos, o Project Management Institute, mais conhecido como
PMI.
Se você é um profissional de gerenciamento de projetos, com certeza já deve ter
ouvido falar do PMI. Se você ainda não se associou, neste capítulo encontrará bons
motivos para se filiar a essa nobre instituição e se envolver voluntariamente nas ativi-
dades dos Capítulos Regionais de seu estado ou cidade.
Este capítulo será muito útil também para o leitor que está pensando em se tornar
um gerente de projetos e necessita de maiores detalhes sobre como obter reconheci-
mento profissional no mercado. Você perceberá que o PMI, junto com seus Capítu-
los, proporciona um perfeito ambiente e um ferramental completo para o fomento e
o desenvolvimento da sua profissão.
Este capítulo está dividido em três seções:
Sobre o PMI
O Programa de Certificação do PMI
Os Capítulos Brasileiros do PMI
Sobre o PMI, veremos brevemente a sua missão, aspectos da sua fundação e dados
estatísticos sobre seus associados.
Quanto ao programa de certificação do PMI, serão abordados de forma resumida
os exames PMP, CAQ e CAPM, bem como seus pré-requisitos. Na seqüência, infor-
marei os locais de realização dos exames no Brasil.
E, por último, veremos os Capítulos Brasileiros do PMI, nos quais serão forneci-
dos os contatos para você obter mais informações sobre as suas atividades.
Sobre o PMI
O PMI foi fundado em 1969 na Filadélfia, Estados Unidos. O Project Management
Institute (PMI) é uma instituição sem fins lucrativos com membros associados em
todo o mundo. A sua missão é “fomentar o profissionalismo e a ética em gerencia-
mento de projetos”.
O PMI e as melhores práticas estruturadas em seu PMBOK – Terceira Edição são re-
ferências mundiais para os profissionais de gerenciamento de projetos. Impossível
falar de gerenciamento de projetos e não citar o PMI, essa nobre instituição que a
cada dia torna-se mais importante para nós, profissionais da área de gerenciamento
de projetos.
Os associados do PMI são profissionais das mais diversas áreas do mercado que
praticam e pesquisam a disciplina de gerenciamento de projetos. Por serem genéri-

ASSOCIAÇÕES E CERTIFICAÇÕES PROFISSIONAIS
CAPÍTULO 10 197
cas, as melhores práticas descritas no PMBOK podem ser aplicadas e adaptadas a

quaisquer tipos de indústrias.
Dados estatísticos sobre os associados do PMI no mundo

As informações a seguir foram gentilmente cedidas pelo Capítulo do PMI-SP e têm
como referência a data de 30 de junho de 2002.
O percentual dos associados do PMI se divide da seguinte forma:
70,91% – Estados Unidos

11,13% – Canadá
17,97% – Fora dos Estados Unidos/Canadá
Número de PMPs no mundo: mais de 50.000
Número de PMPs associados ao PMI-SP: 144
Hoje o Brasil tem nove Capítulos:
Homologados: São Paulo, Rio de Janeiro, Distrito Federal, Paraná, Minas
Gerais, Rio Grande do Sul e Pernambuco
Potenciais: Bahia, Manaus
Número de membros no Brasil: 1161
PMI-SP:
Criado em 1998 a partir de Movimento do Desenvolvimento da Gestão de
Projetos iniciado em 1996, sendo incubado na Faculdade de Economia e
Administração da Universidade de São Paulo.
478 membros até janeiro de 2003, tendo recebido em 2000 o PMI Award como
seção que mais cresceu em 1999.
Em 8 de janeiro de 2003, Pierre Racine (Quebec, Canadá) associou-se ao PMI

como membro de número 100.000. Com este número de associados, o PMI é uma
das maiores associações em todo o mundo.
Atualmente o PMI possui 219.578 membros profissionais, representados em 158
países. É uma das maiores associações profissionais do mundo! Por exemplo, o nú-
mero do PMPs certificados aumentou para 198.048, sendo 6.392 somente na Amé-
rica Latina. Tecnologia da Informação é a área da indústria que possui maior número de
profissionais associados ao PMI: 20.153. A referência para esses números é agosto de
2006. Informações atualizadas sobre o PMI poderão ser acessadas no seguinte link:
http://www.pmi.org/prod/groups/public/documents/info/gmc_memberfactsheet.asp
Chegando lá faça o download do arquivo em PDF do mês e do ano que lhe interessar.
Programa de certificação do PMI

O programa de certificação do PMI iniciou-se em 1984 com os objetivos de promo-
ver a profissão de gerenciamento de projetos e reconhecer a qualificação dos profis-
sionais envolvidos através de padrões rigorosos de exames de certificação.

PMP é a credencial mais reconhecida atualmente para os profissionais de geren-

ciamento de projetos e vem sendo cada vez mais exigida pelas organizações como
pré-requisito para contratações de gerentes de projetos.
Project Management Professional

Para obter a Certificação PMP, o profissional deve satisfazer a determinados requisi-
tos de formação acadêmica, de experiência profissional e estar em concordância e
aderir ao “Código de Conduta Profissional” (Code of Professional Conduct), além de
passar no Exame de Certificação PMP.
Existem duas categorias:
Categoria I (profissionais com Ensino Superior completo), em que são necessá-

rias 4.500 horas e 36 meses de experiência nos últimos seis anos;
Categoria II (profissionais com Ensino Médio completo), em que são necessári-
as 7.500 horas e 60 meses de experiência nos últimos oito anos.
O Exame de Certificação PMP é feito no computador. Você recebe o resultado do

exame logo após a sua realização. O exame custa US$405,00 para quem é associado
do PMI e US$555,00 para quem não é. O pagamento desse exame também é feito
pelo site. Depois de aprovado pelo PMI, você recebe via e-mail a sua Elegibility Letter,
um documento (carta) que comprova que você está apto a realizar o exame. A inscri-
ção para o exame é feita no site do PMI, bem como a inserção das informações sobre a
sua formação acadêmica e experiência profissional.
Além de estar em concordância com o Código de Conduta Profissional, para man-
ter o status de PMP, você deve acumular um mínimo de 60 Professional Develop-
ment Units (PDUs) durante cada ciclo de Continuidade da Certificação. Esse ciclo
tem três anos de duração e começa em 1o de janeiro do ano em que se obteve a certifi-
cação inicial.
PDU é a unidade de medida do PMI utilizada para quantificar atividades aprovadas
de serviço profissional e aprendizagem em gerenciamento de projetos. Você pode
adquirir PDUs de diversas formas: participando de eventos, seminários, cursos pro-
movidos pelos Capítulos ou através de organizações homologadas pelo PMI a minis-
trar cursos de gerenciamento de projetos. Essas PDUs podem também ser obtidas
para cada hora gasta em uma atividade ou experiência de aprendizagem estruturada
planejada. Os profissionais PMPs devem reportar constantemente às suas PDUs,
através do site do PMI. Informações adicionais poderão ser encontradas no CCR
Handbook, disponibilizado no site do PMI. (www.pmi.org)
Conteúdo e Forma do Exame

O exame PMP é composto por 200 questões de múltipla escolha (incluindo cenários
com situações reais) e tem a duração de quatro horas. O exame é corrigido na hora,

CAPÍTULO 10 199
para você saber se passou ao fim da prova. Somente 175 das 200 questões são pontua-
das. Para ser aprovado, você precisa acertar 141 das 175 questões. Das 200 questões,
25 são questões de “pré-teste” que aparecem aleatoriamente ao longo do exame.
Essas 25 questões são utilizadas pelo PMI para estabelecer informações estatísticas e
determinar se elas podem ou devem ser utilizadas em exames futuros.
Antes de 4 de março de 2002, o exame continha cinco domínios: iniciação, plane-
jamento, execução, controle e encerramento. A partir de 4 de março, foi incluído
mais um domínio: responsabilidade profissional.
O percentual das questões do exame é dividido da seguinte forma:
Iniciação do Projeto – 8,5%

Planejamento do Projeto – 23,5%
Execução do Projeto – 23,5%
Controle do Projeto – 23%
Encerramento do Projeto – 7%
Responsabilidade Profissional – 14,5%
Existe uma publicação do PMI chamada The Role Delineation Study, escrita recente-
mente, que está disponível no “PMI on-line bookstore”, onde se detalha o conteúdo
de cada tópico do exame, sendo uma boa fonte de recursos para os candidatos em
preparação para obter a certificação PMP.
Objetivos testados em cada domínio

Domínio 1.0: Iniciação do projeto – 8,5% das questões
Os objetivos deste domínio são:
1. Condução dos métodos de seleção de projetos

2. Definição do escopo
3. Documentação dos riscos, premissas e restrições
4. Identificação e execução da análise dos stakeholders
5. Desenvolvimento do termo de abertura do projeto
6. Obtenção da aprovação do termo de abertura
Domínio 2.0: Planejamento do projeto – 23,5% das questões

1. Definição e registro de requisitos, restrições e premissas

2. Identificação da equipe do projeto e definição de papéis e responsabilidades
3. Criação da EAP
4. Desenvolvimento do plano de gerenciamento de mudanças

5. Identificação de riscos e definição de estratégias de resposta

6. Obtenção da aprovação do plano
7. Condução da reunião de início do projeto
Domínio 3.0: Execução do projeto – 23,5% das questões

1. Execução das tarefas definidas no plano do projeto
2. Garantia de opiniões homogêneas e definição de expectativas
3. Implementação da aquisição de recursos para o projeto
4. Administração da alocação de recursos
5. Implementação do plano de gerenciamento da qualidade
6. Implementação das mudanças aprovadas
7. Implementação das ações e soluções alternativas aprovadas
8. Melhoria do desempenho da equipe
Domínio 4.0: Monitoração e controle do projeto – 23% das questões

1. Mensuração do desempenho
2. Verificação e gerenciamento de mudanças no projeto
3. Garantia das entregas do projeto em conformidade com os padrões de quali-
dade
4. Monitoramento de todos os riscos
Domínio 5.0: Fechamento do projeto – 7% das questões

1. Obtenção da aceitação final para o projeto
2. Obtenção dos fechamentos financeiro, legal e administrativo
3. Liberação dos recursos do projeto
4. Identificação, documentação e comunicação das lições aprendidas
5. Criação e distribuição do relatório final do projeto
6. Arquivamento e manutenção dos registros do projeto
7. Mensuração da satisfação do cliente
Domínio 6.0: Responsabilidade profissional e social – 14,5% das questões

Os objetivos deste domínio são os seguintes:
1. Garantia da integridade individual
2. Contribuição para a base de conhecimentos de gerência de projeto
3. Aperfeiçoamento da competência profissional pessoal
4. Promoção da interação entre os stakeholders

CAPÍTULO 10 201
CAQ – Certificate of Added Qualification

O Certificate of Added Qualification (CAQ) é um programa de certificação específi-
co para PMPs de determinados setores da indústria.
Seus principais objetivos são:
Identificar conhecimentos e habilidades específicos de determinados setores da

indústria que sejam benéficos para o PMP e que pratiquem gerenciamento de
projetos no respectivo setor;
Assegurar que o PMP que tenha obtido a credencial CAQ demonstre conheci-
mentos e habilidades específicos do respectivo setor, satisfazendo critérios de
elegibilidade e passando no exame de conhecimento específico.
O primeiro setor de indústria a ter o CAQ instituído pelo PMI foi o Automotive
Product Development (ADP).
Existem certificações específicas para o setor de tecnologia da informação, tais
como Information Technology Networking e Information Technology-Systems. Mais infor-
mações sobre esses exames poderão ser acessadas nos respectivos links:
http://www.pmi.org/info/PDC_ITNCAQExam.asp
e
http://www.pmi.org/info/PDC_IT-SCAQExam.asp
Outra categoria interessante de certificação CAQ é a Project Management Offi-

ce. São 75 Questões de múltipla escolha sobre o assunto escritório de projetos. Essa pro-
va, assim como outros exames CAQ, possui uma subdivisão que o PMI chama de
“Domains” ou domínios. Os domínios estão divididos em Domain 1 (estratégias, tá-
ticas e operações); Domain 2 (gerenciamento de portfolio); Domain 3 (processos,
padrões e métodos); Domain 4 (desenvolvimento profissional) e Domain 5 (admi-
nistração do conhecimento). Mais informações, acesse o URL: http:// www.pmi.
org/info/PDC_PMOCAQExam.asp
Certified Associate in Project Management

O exame CAPM é para indivíduos praticantes de gerenciamento de projetos que de-
monstrem conhecimentos fundamentais e experiência em gerenciamento de proje-
tos, conduzindo projetos através da utilização de técnicas, ferramentas e metodolo-
gias de gerenciamento de projetos.
O CAPM executa atividades como apoio na avaliação de planos de controle de
projetos; sugestão de limites e métricas de performance; apoio no refinamento dos
requisitos, premissas e restrições do projeto; suporte no encerramento administra-
tivo e financeiro do projeto.

Existem duas categorias de CAPM:

Categoria I (profissionais com Ensino Superior completo), sendo exigidas
1.500 horas e 12 meses de experiência nos últimos dois anos.
Categoria II (profissionais com Ensino Médio completo), sendo exigidas 3.000
horas e 24 meses de experiência nos últimos quatro anos.
O exame é parecido com o exame do PMP; entretanto, ele testará os conheci-
mentos em gerenciamento de projetos de forma mais genérica.
Locais de realização das provas do PMI no Brasil

A seguir, apresento uma lista dos centros autorizados para a realização do exame
PMP:
Center 8324 – Porto Alegre

SYLVAN – ICBNA
Rua Riachuelo, 1257
Porto Alegre,
51-3225-2255 r.249
Center 8317 – Brasília

SYLVAN – Casa Thomas Jefferson
SGAN QD 606, Conjunto B – Asa Norte
Brasília-DF, 70390-065
61-347-4040
Center 8318 – Curitiba

SYLVAN – CCBEU
Rua Maranhão, 2088 – Portão
Curitiba, 80610-001
41-320-4764
Center 8325 – Recife
SYLVAN – ABA
Av. Rosae Silva, 1510
Recife, 52020-220
81-427-0200 r.208
Center 8326 – Rio de Janeiro
SYLVAN – IBEU
Av. N. S. de Copacabana, 690/9o andar
Rio de Janeiro, 22050-000
21-2255-5830

CAPÍTULO 10 203
Center 8328 – São Paulo

SYLVAN – Associação Alummi
Rua Visocnde de Nacar, 86
São Paulo, 05685-903
11-3758-3866 – 3758-7738
Center 8365 – Belo Horizonte
SYLVAN – ICBEU
Rua da Bahia, 1723 – Lourdes
Belo Horizonte, 30160-011
31-3271-7255
Os capítulos brasileiros do PMI

Ao se tornar um associado do PMI, você deve se filiar a um Capítulo, ou Chapter,
como é chamado nos Estados Unidos.
Os Chapters contribuem na missão e nos objetivos do PMI, promovendo o pro-
fissionalismo no gerenciamento de projetos nos negócios, universidades e organiza-
ções profissionais locais. Esse profissionalismo é fomentado através das atividades,
reuniões e outros programas educacionais dos Capítulos, idealizados para fortalecer
o conhecimento, a ciência e a compreensão de princípios, ferramentas e técnicas do
Gerenciamento de Projetos.
O Brasil foi o primeiro país a constituir um Chapter fora dos Estados Unidos, no
início da década de 80. Apesar do interesse já existente na época e de um crescimento
significativo do número de associados, o Chapter Brasil foi destituído em 1984.
Com a nova diretriz de expansão internacional do PMI e o avanço do Gerencia-
mento de Projetos no Brasil, no final da década de 1990, houve uma nova iniciativa
para o estabelecimento de uma entidade nacional voltada para o tema.
As dimensões continentais do país levaram o PMI a incentivar a criação de Chap-
ters por Estados, com o objetivo de manter o ideal de congregação dos profissionais.
O primeiro Capítulo a se estabelecer no Brasil nessa nova fase foi o de São Paulo,
em 1998. Hoje, estão estabelecidos os seguintes Capítulos brasileiros:
Lista atualizada dos capítulos do PMI no Brasil
Data de referência: 30 de Junho de 2006.
Bahia
Anuidade US $ 20.00
Estabelecido em 2003
Sr. Andre Luiz Perrone de Oliveira
WBS Gerenciamento e Empreendimentos Ltda
Rua Frederico Simões, 98 – 16o Andar
Ed Advanced Trade Center

SSA/Bahia – Brasil
CEP 41820-774 – Pituba
Phone: 55-71-273-7530
Fax: 55-71-273-7502
E-Mail: andre@wbsltda.com.br
Brasília – Distrito Federal
Anuidade US $ 20.00
Sr. Rodrigo F. Loureiro, PMP, CEO
ROMA Systems Ltda.
Scln 215, Bl B
Sl 206-209
Asa Norte – Brasília – DF – Brasil
CEP 70874-520
Phone: 55-61-447-9661
Fax: 55-61-272-3471
E-Mail: rodrigo@romasystems.com.br
Chapter Web Site: http://www.pmidf.org
Espírito Santo
Anuidade US $ 20.00
Sr. Paulo Henrique S. Ottoni, PMP
Rua Marins Alvarino, 150 – Itararé
Vitória – ES – Brasil
CEP 29055-410
Phone: 55-273-235-7605
E-Mail: pmies@pmies.org.br
Chapter Web Site: http://www.pmies.org.br
Fortaleza – Ceará
Anuidade US $ 20.00
Sr. Cassio G Soares, M.D., PMP
R Oito de Setembro, 1214, apto. 1.302 – Varjota
Fortaleza – CE – Brasil
CEP 60175-210
Fax: 55-85-88444049
Phone: 55-85-3216-7864
E-Mail: cassio@pmice.org.br
Chapter Web Site: http://www.pmice.org.br

CAPÍTULO 10 205
Goiânia – Goiás
Anuidade US $ 20.00
Mrs. Sulema de Oliveira B Gobato, Sr., PMP, President
Av. Perimetral Norte No. 4.129
Villa Joao Vaz
Goiânia, Goiás – Brasil
CEP 74445-190
Phone: 55-62-231-6562
E-Mail: sulemagobato@yahoo.com.br
Chapter Web Site: http://www.pmigo.org.br
Brazil – Paraná
Anuidade US $ 20.00
Sr. Jose B. Souza, President
Po Box 4130
Curitiba – PR – Brasil
Phone : 55-41-3016 2101
Fax : 55-41-3016 2102
E-Mail: souza@pm21.com.br
Chapter Web Site: http://www.pmipr.org.br
Joinville – Santa Catarina
Anuidade US $ 20.00
Sr. Marcio Clovis Schaefer, Jr.
Rua Max Colin 1.214, apto. 801
Bairro América
Joinville – SC – Brasil
CEP 89204-040
E-Mail: marcio.filho@datasul.com.br
Chapter Web Site: http://www.pmisc.org.br
Manaus
Anuidade US $ 20.00
Sr. Rubenson Marcelo Sousa Chaves, President
Alameda Cosme Ferreira 7311
Condomínio Opera de Paris, apto. 304
Aleixo
Manaus Amazonas – Brasil

CEP 69083-000
Phone: 55-92-644-4783
Fax: 55-92-644-3766
E-Mail: rubenson.chaves@pmiam.org
Chapter Web Site: http://www.pmiam.org
Minas Gerais
Anuidade US $ 20.00
Sr. Antonio José Soares, PMP, President
R Tomé de Souza, 67 – 3o andar
Belo Horizonte – MG – Brasil
CEP 30140 130
Phone: 55-31-3287 0422
Fax: 55-31-3287-0423
E-Mail: presidencia@pmimg.org.br
Chapter E-mail: pmimg@pmimg.org.br
Chapter Web Site: http://www.pmimg.org.br
Recife – Pernambuco (Brazil Chapter)
Anuidade US $ 20.00
Sr. Douglas Balduino Guedes da Nobrega, PMP, President
R. Manoel Almeida Belo, 1.183, apto. 502
Bairro Novo
Olinda – Brasil
CEP 53030-030
Phone: 55-81-3229-2218
E-Mail: douglas.nobrega@pmipe.org.br
Chapter Web Site: http://www.pmipe.org.br
Rio Grande do Sul
Anuidade US $ 20.00
Sr. Marco K. Ribeiro, President
Avenida Ipiranga, 6681 – Tecnopuc
Porto Alegre, RS
Rio Grande do Sul – Brasil
CEP 90619-900
Phone: 55-51-3319-1757
Fax: 55-51-3319-1757
E-Mail: marco.kappel@pmirs.org.br
Chapter Web Site: http://www.pmirs.org/

CAPÍTULO 10 207
Rio de Janeiro
Anuidade US $ 20.00
Sr. Angelo Valle
Av. Franklin Roosevelt, 194 – Gr. 304
Centro – Rio de Janeiro – Brasil
CEP 20021-120
Phone: 55-21-2262-8985 / 2262-8579
E-Mail: angelo.valle@fgvmail.br
Chapter Web Site: http://www.pmirio.org.br/
São Paulo
Anuidade US $ 20.00
Sr. Marcio Prieto
Alameda dos Maracatins, 992 – cj. 104-B
Sao Paulo – SP – Brasil
CEP 04089-001
Phone: 5511-5041-4144
Fax: 5511-5531-1920
E-Mail: presidencia@pmisp.org.br
Chapter Web Site: http://www.pmisp.org.br
Os contatos dos Capítulos mudam de acordo com os critérios de renovações de

diretorias. Para mais informações, acesse os respectivos sites ou e-mails. Visite cons-
tantemente o site do PMI para informações mais atualizadas.
ABGP – ASSOCIAÇÃO BRASILEIRA DE GERENCIAMENTO DE PROJETOS

Introdução
A Associação Brasileira de Gerenciamento de Projetos – ABGP – é uma entidade de
âmbito nacional, sem fins lucrativos e de natureza privada. A ABGP está voltada a de-
senvolver e aprimorar as atividades de Gerenciamento de Projetos em todas as suas
modalidades, contribuindo para a melhoria da prática nas organizações. Suas ativida-
des se concentram em:
Certificação.
Eventos.
Treinamento e qualificação.
Publicações.
Clube ABGP.

O contexto profissional atual apresenta um conjunto de razões para você, profis-

sional que atua em Gerenciamento de Projetos, associar-se:
A profissão de Gerente de Projetos está se transformando, ampliando os seus

espaços e seu potencial de agregar valor.
O número de profissionais certificados está crescendo rapidamente no mundo
todo.
Hoje, a disciplina de Gerenciamento de Projetos é a que mais cresce no
mundo.
Muitas organizações, em muitos países, estão condicionando a assinatura de
contratos de aquisição de produtos/serviços à existência de pessoal qualificado
Categoria de sócios
Sócios membros: profissionais interessados no tema Gerenciamento de Proje-
tos, com formação acadêmica de nível superior – excepcionalmente, mediante
aprovação da Direção, também pessoas sem curso superior.
Sócios mantenedores: entidades públicas ou privadas que desejem patrocinar
os objetivos da ABGP.
Sócios estudantes: alunos (graduação e pós-graduação) regularmente matricu-
lados em instituições de ensino superior reconhecidas pelo MEC.
Sócios honorários: pessoas físicas, expoentes no tema Gerenciamento de Pro-
jetos, a quem a ABGP venha a convidar e aprovar em Assembléia Geral.
Sócios fundadores: outorgantes da escritura de constituição da ABGP.
Resumo do estatuto
ABGP é uma organização de âmbito nacional, sem fins lucrativos e de natureza
privada.
Objetivo principal: contribuir para a melhoria da prática da profissão de Geren-
te de Projeto.
Principais atividades: treinamentos, consultorias, divulgação e participação em
eventos no tema.
Categorias de sócios: membros, mantenedores, estudantes, honorários e fun-
dadores.
Estrutura organizacional:
Assembléia Geral (órgão máximo e soberano)
Direção (Presidente, Vice-presidente, Diretor Científico e Diretor Finan-
ceiro)
Conselho Fiscal.
Os integrantes da Direção são voluntários.
Secretário-geral para atividades de apoio administrativo.

CAPÍTULO 10 209
Coordenadores Técnicos em áreas temáticas.

Gerente Executivo (criação a critério do Presidente).
Receitas a partir de jóias e quotas, serviços, bens próprios, fundos de reserva
ou depósitos.
Como se associar
Razões para associar-se
A profissão de Gerente de Projetos está se transformando e ampliando os seus
espaços e potencial de agregar valor.
O número de profissionais certificados está crescendo rapidamente no mun-
do todo.
A disciplina de Gerenciamento de Projetos é a que mais cresce no mundo hoje.
Muitas organizações, em muitos países, estão condicionando a assinatura de
contratos de aquisição de produtos/serviços à existência de pessoal qualificado
Os padrões da ABGP/IPMA são reconhecidos internacionalmente.
Atualmente existem mais de 40 países associados à IPMA, que disseminam a
disciplina de Gerenciamento de Projetos e promovem a valorização da profis-
são de Gerente de Projetos.
Vantagens ao associar-se
Taxas de inscrição diferenciadas para participação em eventos promovidos ou
patrocinados pela ABGP.
Descontos especiais em Editoras e/ou Livrarias conveniadas.
Acesso à área exclusiva de download da ABGP.
Recebimento de periódicos da ABGP.
Acesso à lista de especialistas em GP (pessoas certificadas).
Informações recentes sobre métodos, técnicas e ferramentas em GP.
Fazer parte da comunidade (network) de profissionais e praticantes de Gerencia-
mento de Projetos preocupados em melhorar e valorizar a profissão.
Informações para atualização profissional permanente em GP.
Ampliação e melhoria constante do corpo de conhecimentos, da experiência e
de atitudes frente ao Gerenciamento de Projetos.
Possibilidade de compartilhar conhecimentos e experiências em encontros pe-
riódicos formais e informais da ABGP.
Proposta de filiação
O Formulário de Proposta de Filiação (disponível no CD que acompanha este
livro na pasta \ABGP\ DOWNLOADS) é o instrumento básico de solicitação
de participação como sócio na ABGP. A proposta deve ser acompanhada de do-
cumentação comprobatória de curso de nível superior. As solicitações de filia-
ção são avaliadas e deferidas ou não nas reuniões ordinárias da Diretoria.

Todo e qualquer pagamento de anuidade somente deverá ser realizado após a

confirmação do aceite do candidato como sócio da ABGP.
Encaminhamento
Via e-mail:
O candidato pode utilizar o formulário disponível no CD que acompanha este
livro ou fazer o download do Formulário da Proposta de Filiação (documento
em formato Word) no site da ABGP: www.abgp.org.br, preencher os campos
solicitados e encaminhar em arquivo anexado para abgp@abgp.org.br. Cópia
de documento comprobatório de curso de nível superior deve ser encaminhada
como anexo.
Anuidade e Taxas
As anuidades e taxas são reajustadas periodicamente pela ABGP. Anuidades vigentes
em 2006:
Sócio membro: R$ 80,00, com vencimento anual nas datas subseqüentes ao
primeiro ano de filiação.
Sócio estudante (graduação, especialização, MBA, mestrado e doutorado) de
curso reconhecido pelo MEC: R$ 40,00, com vencimento anual nas datas sub-
seqüentes ao primeiro ano de filiação.
Sócio mantenedor: valores são definidos em função do número de funcionários
de cada organização.
IMPORTANTE! Todo e qualquer pagamento de anuidade somente deverá ser
realizado após a confirmação do aceite do candidato como sócio da ABGP.
Taxa de filiação vigente em 2006:

Atualmente a ABGP não cobra taxa de filiação.
Parceiros e links
IPMA – www.ipma.ch
AFITEP – www.afitep.fr
APM – www.apm.org.uk
APOGEP – www.apogep.pt
Revista MundoPM – www.mundopm.com.br
Sistema FIEP – www.fiepr.org.br
Contatos
Secretaria-geral: abgp@abgp.org.br
Presidente da ABGP: Dr. Silvio Aurélio de Castro Wille – silviowille@abgp.org.br
Telefones: 55-41– 9923-2200
55-41-3222-8900

CAPÍTULO 10 211
Vice-presidente: Jorge Luciano Gil Kolotelo – kolotelo@abgp.org.br

Diretora-financeira: Lisiane Zynger Capaverde – lisiane@abgp.org.br
Endereço para correspondência:
ABGP
Rua Padre Manuel da Nóbrega, 1981
Curitiba – PR
CEP 81030-330
Certificação em GP
Objetivos do Programa de Certificação ABGP/IPMA:
Certificar profissionais em Gerenciamento de Projetos, com base no conheci-
mento, na experiência e nas atitudes pessoais, com validação internacional.
Desenvolver o Gerenciamento de Projetos em todas suas modalidades e incen-
tivar o melhoramento da prática da profissão, no Brasil e no exterior.
Contribuir para a formação e a educação em Gerenciamento de Projetos.
Vantagens ao certificar-se
Para os profissionais de Gestão de Projetos: um certificado internacionalmente
reconhecido das suas qualificações e competências.
Reconhecimento, em nível nacional e internacional, de qualificação pessoal
atualizada em Gerenciamento de Projetos.
Demonstração de estar com qualificação e competências nos patamares dos pa-
drões internacionais.
Potencial melhoria na carreira profissional.
Para os prestadores de serviços de Gestão de Projetos: a demonstração da quali-
ficação e competência profissional dos seus gerentes, gestores e empregados.
Para os clientes: assegurar que são recebidos serviços de Gerenciamento de
Projetos profissionais, seguindo o estado da arte em termos de métodos, técni-
cas e ferramentas.
Níveis da certificação
Para tanto, a ABGP/IPMA desenvolve um Programa de Certificação estruturado
em quatro níveis. Este programa é validado e fiscalizado pela própria IPMA com re-
gularidade e efetividade.
IPMA Level A – Diretor de Projetos Certificado:
Deve ter a capacidade de dirigir todos os projetos constituintes de um progra-
ma ou todos os projetos de uma empresa ou linha de negócio, ou ainda um pro-
jeto complexo com participantes de diferentes culturas e geografias.
IPMA Level B – Gerente de Projetos Senior Certificado:
Deve ser capaz de gerenciar projetos complexos com total independência.

IPMA Level C – Gerente de Projetos Certificado:

Deve ser capaz de gerenciar, com razoável independência, projetos não com-
plexos e apoiar o gestor de um projeto complexo em todas as áreas de aplicação
do Gerenciamento de Projetos.
IPMA Level D – Associado em Gerenciamento de Projetos Certificado:
Deve ter conhecimentos em Gerenciamento de Projetos, os quais poderão ser
aplicados em alguns campos da sua especialidade.
Regras para a certificação

Compete às Associações Nacionais desenvolver e gerir os Programas de Certifica-
ção aprovados pela IPMA para vigorarem nos respectivos países e estabelecerem,
em ligação com a IPMA, os Conselhos Nacionais de Certificação. A IPMA é res-
ponsável por manter um sistema universal para validação dos programas nacionais
e pela coordenação e harmonização das certificações de acordo com sua estrutura
geral e seus princípios.
Estrutura geral e princípios

A estrutura geral é apresentada no documento International Competence Baseline
(ICB), que descreve as áreas de qualificação da competência em gerência de proje-
tos, bem como a taxionomia utilizada para a avaliação do conhecimento, experiência
e atitude pessoal dos profissionais de gerência de projetos. O ICB está disponível em
inglês (adotado como versão standard pela IPMA), alemão e francês. São usadas as
seguintes referências:
Inglês: UK Body of Knowledge (APM).

Alemão: Beurteillungsstruktur (VZPM) e o German PM-Kanon (PM-Zert).
Francês: Critères d’Analyse (AFITEP).
As estruturas de avaliação são constituídas por descrições e taxionomias. Os crité-

rios quantificam as capacidades genéricas, os princípios da gestão de projetos, as
competências sociais e organizacionais, os métodos e os procedimentos, os concei-
tos genéricos de gerência e a atitude pessoal. Essas áreas estão estruturadas em cerca
de 40 elementos de avaliação.
Cada Associação Nacional é responsável por estabelecer a sua própria definição de
competências (NCB), as quais devem ser conformes com o ICB e levarem em consi-
deração as especificidades culturais de cada país.
A ABGP já disponibilizou sua primeira versão (2005) do NCB Brasileiro, intitula-
do Referencial Brasileiro de Competências em Gerenciamento de Projetos (RBC) que
está disponível para download no seu site www.abgp.org.br. Com o lançamento do
novo ICB v3 (veja o próximo item), a ABGP e seus associados estarão divulgando em
2007 o NCB Brasileiro atualizado para refletir o novo ICB.

CAPÍTULO 10 213
Lançamento do novo ICB

A IPMA anunciou o lançamento do novo ICB v3 (IPMA Competence Baseline), um tra-
balho que reforça a certificação IPMA como o padrão platinum para certificação de
profissionais de gerenciamento de projetos. Gerrit Koch é o gerente do projeto des-
te novo padrão.
O ICB v3 foi concebido para ser facilmente compreendido e utilizado, além de ser
customizável por organizações nacionais de certificações. Data prevista de lança-
mento desse trabalho: início do segundo semestre de 2006.
O novo ICB da IPMA está baseado no “Olho da Competência” (The Eye of Compe-
tence), que representa a integração de todos os elementos do gerenciamento de pro-
jetos vistos pela ótica do gerente de projetos, na avaliação de uma situação específica.
O olho representa a transparência e a visão. Após processar a informação recebida, o
profissional competente e responsável pelo gerenciamento de projetos toma a ação
apropriada.
F I G U R A 1 0 . 1 O Olho da Competência – Fonte: ABGP/IPMA]
O ICB v3 define 46 elementos de competência, complementados pelas rela-

ções-chave entre eles e descritos em três grupos: competências técnicas, comporta-
mentais e contextuais.
O ICB v3 é um documento que apresenta dois usos principais. O primeiro, é o de
disseminar conceitos e competências em GP, e assim, pode e deve ser usado como
um guia na preparação de materiais de treinamentos, para pesquisas e como um do-
cumento geral para as pessoas que estão em busca de informações sobre gerencia-
mento de projetos aplicados. O segundo uso, específico, é aquele voltado à certifica-

ção em GP, tanto aquelas conduzidas dentro das organizações como a conduzida pe-
las associações nacionais participantes da família IPMA. Neste caso, o ICB v3 deve
ser usado por indivíduos e avaliadores que estão conduzindo uma avaliação. O ICB 3
será mundialmente reconhecido por associações profissionais de gerenciamento de
projetos. Fique de olho!
Maiores informações sobre o ICB v3 poderão ser obtidas na ABGP.
Clube ABGP
A ABGP incentiva a formação de Clubes ABGP em todo o Brasil. Para isso ela dispo-
nibiliza elementos facilitadores da montagem desses clubes, inclusive fornecendo
aos interessados um modelo de estatuto.
O objetivo tanto da ABGP como desse Clube é estimular e fomentar a dissemina-
ção do gerenciamento de projetos em todo o Brasil, e entende que este trabalho será
efetuado de forma mais ampla se puder contar com voluntários dignos e interessa-
dos, promovendo e apoiando:
Primeiro. O desenvolvimento do companheirismo como elemento capaz de propor-

cionar oportunidades de servir à causa de disseminar o gerenciamento de projetos na
sua região.
Segundo. O reconhecimento do mérito de atuar de forma voluntária, sem nenhum
ganho financeiro de qualquer espécie, aplicando e difundindo as normas de ética pro-
fissional da ABGP;
Terceiro. A melhoria da comunidade pela divulgação do uso de gerenciamento de
projetos nas áreas pública, privada e do terceiro setor, conduzida por cada um dos as-
sociados com uma conduta exemplar na sua vida pública e privada.
Quarto. A aproximação dos profissionais de gerenciamento de projetos brasileiros e
de todo o mundo, visando à troca de experiências e conhecimento em gerenciamen-
to de projetos bem como a consolidação das boas relações e da cooperação entre pro-
fissionais de toda as nações.
Reuniões
O clube utilizará tanto a comunicação presencial como a eletrônica (incluindo a
Internet e tecnologias congêneres) para promover a apresentação e discussão partici-
pativa de matérias e tópicos apropriados, bem como as atividades voluntárias dos
projetos do Clube.
Participação
Qualificações gerais. Todos os sócios desse clube deverão participar das atividades do
clube e das reuniões presenciais e/ou eletrônica do mesmo. Um membro será consi-
derado como participante de uma atividade se o mesmo tomar parte no desenvolvi-

CAPÍTULO 10 215
mento da mesma e/ou tomar parte nas discussões de como lidar com a atividade.
Atividades Voluntárias em GP – Gerenciamento de Projetos. Cada Sócio do clube
deverá contribuir, no mínimo, com doze horas de atividades voluntárias por trimes-
tre, bem como participar das atividades periódicas do clube. Atividade voluntária
em Gerenciamento de Projetos é definida como qualquer participação efetiva em
atividades do clube, como a realização de palestras sobre a ABGP e sobre gerencia-
mento de projetos, participação em grupos de estudo do RBC – Referencial Brasilei-
ro de Competências em Gerenciamento de Projetos e/ou ICB – IPMA Competence
Baseline e realização de atividades de projetos do Clube.
Arquivos
No CD que acompanha este livro, na pasta \ABGP\DOWNLOADS\, o leitor en-
contrará os seguintes arquivos:
Referencial Brasileiro de Competências para GPs – RBC versão 2005
Formulário Proposta de Filiação
Formulário de pré-candidatura 2006 – ABERTA
Kit de formulários e elementos para a Certificação ABGP/IPMA Nível D de 2006:
Procedimentos para Certificação ABGP/IPMA Nível D.
Ementa e Objetivos de Aprendizagem Nível D.
Cronograma para a Certificação Nível D.
Critérios para auto-avaliação.
Formulário 1 para auto-avaliação.
Formulário de Candidatura à Certificação ABGP/IPMA 2006.
Kit de formulários e elementos para a Certificação ABGP/IPMA Nível C de 2006:
Procedimentos para Certificação ABGP/IPMA Nível C.
Ementa e Objetivos de Aprendizagem Nível C.
Cronograma para a Certificação Nível C.
Critérios para auto-avaliação.
Formulário de Candidatura à Certificação ABGP/IPMA 2006.
AACE – THE ASSOCIATION FOR THE ADVANCEMENT OF COST ENGENEERING

Introdução
Fundada em 1956, AACE International é uma associação de profissionais especialis-
tas em estimativas de custos e controle de projetos.
Com mais de 5.500 membros em todo mundo, a AACE International é a maior
organização para os profissionais da área de gestão de custos. Possui membros em 78
países e 71 capítulos locais.

Benefícios
Mensalmente os associados da AACE recebem o Cost Engineering Journal – uma publica-
ção internacional sobre estimativa e controle de custos e gestão de projetos. Esta publi-
cação provê artigos e informações atualizadas sobre a área de gestão de custos.
A AACE promove seminários anuais e reuniões em seus capítulos locais, permi-
tindo melhorar o expertise profissional e as habilidades técnicas na área de gestão de
custos.
No AACE Online Bookstore é possível adquirir publicações relacionadas à gestão
de custos e gerenciamento de projetos, tais como as melhores práticas, livros, dentre
outros.
Library – Os membros da AACE International recebem acesso livre a maior base
de dados do mundo sobre estimativas de custos, controle de custo e literatura sobre
gestão de projetos.
Informação Online – No site da AACE os membros podem acessar o Cost Engine-
ering Journal, referências de 8.000 publicações técnicas, um banco de dados com
milhares de artigos e livros e atualizações das melhores práticas e padrões.
Certificações – Seja reconhecido como um líder na sua profissão tornando-se um
Certified Cost Engineer (CCE) ou Certified Cost Consultant (CCC). São as únicas
certificações reconhecidas internacionalmente na área de gestão de custos.
Novas certificações
As novas certificações da AACEI são:
Interim Cost Consultant (ICC)
Earned Value Professional (EVP)
Planning & Scheduling Professional (PSP).
No CD que acompanha este livro, na pasta \AACEI, você poderá acessar informa-
ções detalhadas sobre as certificações, bem como exemplos de questões.
Web site
Acesse o site da AACE International para maiores informações: http://www.aacei.org
ISACA – INFORMATION SYSTEMS AUDIT AND CONTROL ASSOCIATION

Introdução
Com mais de 35.000 membros em 100 países, a Information Systems Audit and
Control Association (ISACA) (www.isaca.org) é reconhecida internacionalmente
como líder em Governaça de TI, controle, segurança e seguros. O COBIT abordado
no Capítulo 1 foi desenvolvido pela ISACA.
Fundada em 1969, a ISACA patrocina conferências internacionais, publica o Infor-
mation Systems Control Journal, desenvolve padrões internacionais de auditoria e con-

CAPÍTULO 10 217
trole de sistemas de informação, administra a designação Certified Information

Systems Auditor (CISA) respeitado mundialmente, obtida por mais de 35.000 pro-
fissionais desde seu lançamento, e a designação Certified Information Security Ma-
nager (CISM), uma credencial importante obtida por 5.000 profissionais nos dois
primeiros anos de seu lançamento.
Certificados profissionais: CISA e CISM

CISA – Certified Information Systems Auditor.
A marca de excelência para os profissionais interessados em obter um diferencial no
mercado de Segurança da Informação e Auditoria de Sistemas.
No CD que acompanha este livro, na pasta \ISACA\CISA\, você encontrará um
arquivo (em inglês) chamado “CISA-BOI-JUNE-NEW-LOGO.PDF”, contendo in-
formações sobre o exame CISA, tais como:
Informações sobre o exame CISA.
Os pré-requisitos para se qualificar para fazer o exame.
Como se preparar para fazer a prova utilizando as indicações bibliográficas e
CD com exemplos de questões.
Como manter a sua certificação.
Como se registrar para fazer a prova (incluindo taxas).
Resultado do teste.
Benefícios de se tornar membro da ISACA.
Instruções para preenchimento do “Registration Form”.
Nessa pasta você encontrará uma mesma versão deste arquivo em espanhol, cha-
mado “CISA_BOI_spanish.PDF”.
CISM – Certified Information Security Manager

Marca de excelência para os profissionais interessados em obter um diferencial no
mercado de Segurança da Informação e Auditoria de Sistemas.
No CD que acompanha este livro, na pasta \ISACA\CISM\, você encontrará um
arquivo chamado “CISM-BOI-JUNE.PDF”, contendo informações sobre o exame
CISM, tais como:
Informações sobre o exame CISM.
Como se preparar para fazer a prova utilizando as indicações bibliográficas e
CD com exemplos de questões.
Como manter a sua certificação.
Como se registrar para fazer a prova (incluindo taxas).
Resultado do teste.
Benefícios de se tornar membro da ISACA.
Instruções para preenchimento do “Registration Form”.

Existe também a versão deste arquivo em espanhol, chamado “CISM_BOI_spa-

nish.PDF”.
Observação importante: os arquivos citados anteriormente se aplicam à versão
2006 dos exames CISA e CISM.
Aproveite para ler também o arquivo “certification-sucess-brochure.pdf”, que se
encontra na pasta \ISACA.
Você encontrará exemplos de questões do exame CISA no próprio site da ISACA,
no link: http://www.isaca.org/cisaexam. Chegando lá, clique em “Sample Questions”
e responda ao questionário contendo 25 questões. Após responder, clique no botão
“Check My Score”. Os resultados aparecerão em outra janela numa tabela com o
percentual de questões de cada área, com as escolhas que você fez, se estão corretas
ou erradas e a explicação para cada resposta.
Cursos preparatórios para certificação CISA e/ou CISM

A ISACA-São Paulo em parceria com a ABBC – Associação Brasileira de Bancos –
propicia uma oportunidade exclusiva para que você se torne um profissional certifi-
cado com reconhecimento internacional, participando de dois cursos: “Curso de
Preparação para o Exame de Certificação CISA” e “Curso de Preparação para o Exa-
me de Certificação CISM”.
A seguir, o conteúdo dos dois cursos.
“Curso de Preparação para o Exame de Certificação CISA”

Carga horária total: 90 horas.
Inclui dois exames simulados com revisão em dois sábados.
São cerca de 600 questões (em inglês) comentadas e discutidas em sala de aula
(em português) e dois exames simulados, com duração de quatro horas mais
quatro horas para revisão.
O curso é ministrado por instrutores da ISACA-São Paulo e por profissionais de
renome no mercado, que atuam nas áreas de auditoria de sistemas e de consul-
toria em segurança da informação.
Áreas cobertas:
1. Processo de Auditoria de Sistemas de Informação (The IS Audit Process).
2. Organização, Planejamento e Gerenciamento de TI (Management Plan-
ning and Organization of IS).
3. Infra-estrutura Técnica e Práticas Operacionais (Technical Infrastructure
and Operational Practices).
4. Proteção dos Recursos de Informação (Protection of Information Assets).
5. Recuperação de Desastre e Plano de Continuidade dos Negócios (Desas-
ter Recovery and Business Continuity).

CAPÍTULO 10 219
6. Desenvolvimento, Aquisição, Implementação e Manutenção de Sistemas

Aplicativos (Business Application System. Development, Acquisition,
Implementation and Maintenance).
7. Avaliação dos Processos de Negócio e Gestão de Riscos (Business Process
Evaluation and Risk Management).
Local: Sede da ABBC, à Av. Paulista, 1499 – 1o andar – São Paulo, SP.
“Curso de Preparação para o Exame de Certificação CISM”

Carga horária total: 90 horas.
Inclui dois exames simulados com revisão em dois sábados.
São cerca de 600 questões (em inglês) comentadas e discutidas em sala de aula
(em português) e dois exames simulados, com duração de quatro horas mais
quatro horas para revisão.
O curso é ministrado por instrutores referendados pela ISACA-São Paulo e por
profissionais de renome no mercado, que atuam preferencialmente nas áreas
de segurança da Informação, em auditoria de sistemas, assim como de consul-
torias em segurança da informação e auditoria de sistemas.
Áreas cobertas:
1. Governança da Segurança da Informação (Information Security Gover-
nance).
2. Gestão de Risco (Risk Management).
3. Gestão do Programa de Segurança da Informação (Information Security
Program Management).
4. Gestão da Segurança da Informação (Information Security Management).
5. Gestão de Resposta (Response Management).
Local: Sede da ABBC, à Av. Paulista, 1499 – 1o andar – São Paulo, SP.
Informações e Inscrições: Direto na ABBC, através do telefone (011) 288-1688

ou do e-mail: eventosabbc@abbc.org.br
Links relacionados ao COBIT

www.ITgovernance.org
The IT Governance Institute.
www.isaca.org
Information Systems Audit and Control Association.
www.isaca.org.br
Information Systems Audit and Control Association do Brasil.
www.coso.org
Committee of the Sponsoring Organizations of the Treadway Commission.
www.sec.gov
The US Securities and Exchange Commission – SEC).

Referências bibliográficas
“An Audit of Internal Control Over Financial Reporting Performed in Conjunction with an Audit of
Financial Statements”, Public Company Accounting Oversight Board, Final Auditing Standard:
Release No. 2004-001, EUA, 9 de março de 2004.
COBIT, IT, Governance Institute, Rolling Meadows, Illinois, EUA, julho de 2000.
Committee of Sponsoring Organizations of the Treadway Commission (COSO), www.coso.org.
Common Criteria and Methodology for Information Technology Security Evaluation, CSE (Cana-
da), SCSSI (France), BSII (Germany), NLNCSA (Netherlands), CESG (United Kingdom), NIST
(USA) and NSA (EUA), 1999.
Exposure Draft Enterprise Risk Management Framework, Committee of Sponsoring Organizations
of the Treadway Commission (COSO), EUA, julho de 2003.
“Final Rule: Management’s Reports on Internal Control Over Financial Reporting and Certification
of Disclosure in Exchange Act Periodic Reports”, Release Nos. 33-8238; 34-47986; IC-26068;
File Nos. S7-40-02; S7-06-03, US Securities and Exchange Commission, USA, junho de 2003,
www.sec.gov/rules/final/33-8238.htm.
Internal Control –Integrated Framework, Committee of Sponsoring Organizations of the Treadway
Commission (COSO), American Institute of Certified Public Accountants, USA, 1992.
ISO IEC 17799, Code of Practice for Information Security Management, International Organization
for Standardization (ISO), Suíça, 2000.
IT Infrastructure Library (ITIL), British Office of Government Commerce (OCG), Central Compu-
ter and Telecommunications Agency (CCTA), Londres, 1989.
Moving Forward – A Guide to Improving Corporate Governance Through Effective Internal Con-
trol, Deloitte & Touche, 2003.
“Taking Control, A Guide to Compliance with Section 404 of the Sarbanes-Oxley Act of 2002”, De-
loitte & Touche, 2003.
“The Defining Issues – Implications of Proposed Auditing Standard on Internal Control”, KPMG,
2003.
“The Sarbanes-Oxley Act of 2002, Strategies for Meeting New Internal Control Reporting Challen-
ges”, PricewaterhouseCoopers, 2003.
“The Sarbanes-Oxley Act of 2002, The Current Landscape – Rules, Updates and Business Trends”,
Ernst & Young, 2003
“Understanding the Independent Auditor’s Role in Building Trust”, PricewaterhouseCoopers, 2003.
COBIT 3a ed., IT Governance Institute, 2000, www.isaca.org/cobit.htm
COSO, 1992, Internal control-integrated framework.
Guldentops, E., “Asking the Right Questions for IT Governance”, Information Systems Control Journal,
volume 4, 2001.
Guldentops, E., “Boards and IT – Unleash the Value, Put a Leash on the Risks”, Information Systems
Control Journal, volume 2, 2002.
Institute of Internal Auditors, “The board’s strategic role”, Tone at The Top, número 8, 2000.
IT Governance Institute, Board Briefing on IT Governance, 2001, www.ITgovernance.org/resour-
ces.htm.
Kakabadse, N. K., and A. Kakabadse, “IS/IT governance: Need for an integrated model”, Corporate
Governance, volume 1, número 9, 2001.
Ministry of International Trade and Industry, “Corporate approaches to IT governance”, 1999,
www.jipdec.or.jp/chosa/MITIBE/sld001.htm.
Parkes, H., “IT Governance: Putting It in Perspective”, Information Systems Control Journal, volume 3,
2001.
Scottsdale Institute, “Closing the Governance Gap: Bringing Boards into the IT Equation”, Informa-
tion Edge, volume 7, número 7, 2001.

CAPÍTULO 10 221
Van Grembergen, W., and R. Saull, “Aligning Business and Information Technology through the Ba-
lanced Scorecard at a Major Canadian Financial Group”, Proceedings of the 9th Hawaii Internati-
onal Conference on System Sciences (HICSS), CD-ROM, Maui, 2001.
Williams, P., “Bring the board online with IT governance”, ComputerWeekly, 2001, www.cw360.com.
IT Governance Institute, COBIT (Control Objectives for Information and related Technology) 3rd
Edition, 2000, www.ITgovernance.org e www.isaca.org.
International Federation of Accountants, Managing Security of Information, 1998.
American Institute of Certified Public Accountants/Canadian Institute of Chartered Accountants,
SysTrust Principles and Criteria for Systems Reliability V 2.0, 2001.
International Organisation for Standardisation, Standard 17799, 2000.
US General Accounting Office, Information Security: Computer Attacks at Department of Defense
Pose Increasing Risks, 1996, www.fas.org/irp/gao/aim96084.htm.
British Standards Institution, BS 7799-2 – Code of Practice for Information Security Management,
1999.
Peter Weill and Marianne Broadbent, Leveraging the New Infrastructure: How Market Leaders Capitalize
on Information Technology, Harvard Business School Press, 1998.
Robert S. Kaplan and David P. Norton, The Balanced Scorecard: Translating Strategy into Action, Har-
vard Business School Press, 1996.
Robert S. Kaplan and David P. Norton, The Strategy-Focused Organization, Harvard Business School
Press, 2001.
S. Mingay et al, The Five Pillars of IS Organisational Effectiveness, Gartner Group, 1998.
Various Gartner research notes on IT Alignment and IT Value Delivery, 1996 – 2000.
J. Luftman, P. Lewis and S.Oldach, “Transforming the Enterprise: The Alignment of Business and
Information Technology Strategies”, IBM Systems Journal, 32, 1, pp. 198-221, 1993.
PricewaterhouseCoopers and The Institute of Internal Auditors Research Foundation, Corporate
Governance and the Board – What Works Best, 2000.
PRMIA – THE PROFESSIONAL RISK MANAGERS’ INTERNATIONAL ASSOCIATION

Introdução
A PRMIA (Professional Risk Managers’ International Association) é uma associação
internacional dos profissionais que lidam com gestão de riscos.
Em 8 de abril de 2006 a PRMIA possuía 32.527 membros em 169 países e capítu-
los locais em 60 cidades no mundo. Em média, por mês, 800 novos membros se asso-
ciam à PRMIA.
PRMIA Institute
O PRMIA Institute é uma entidade sem fins lucrativos que trabalha em parceria com
universidades definindo as melhores práticas e ementas para cursos de graduação de
gestão de riscos e matemática financeira.
Além disso, é responsável pelas publicações da PRMIA, disponibilização de cur-
sos on-line e fomentação de bolsas de estudos e descontos em algumas universidades.
Certificação PRM
O programa de certificação PRM – Professional Risk Manager – é o padrão global
para os profissionais de riscos financeiros.

Além da experiência, o candidato à certificação PRM conta com materiais de

apoio e recursos disponibilizados no site da PRMIA:
Professional Risk Managers’ Handbook: A Comprehensive Guide to Current
Theory and Best Practices;
PRMTM Study Guide;
Cursos preparatórios on-line;
Exames de diagnósticos e Treinamentos.
Recursos para os associados

Além dos benefícios supracitados, os membros associados à PRMIA podem acessar o
Rose Search Engine, uma ferramenta de pesquisa diferente dos mecanismos de busca
convencionais, provendo ao associado links específicos e um rico conteúdo na área
de gestão de riscos.
Com a ajuda do Web Metasearch o associado pode fazer pesquisas mais aprofun-
dadas nos dicionários financeiros, fóruns de discussão, Weblogs e no banco de dados
ROSE da PRMIA.
A PRMIA promove diversos eventos internacionais: seminários, conferências,
congressos. É possível fazer uma busca por eventos passados escolhendo uma pala-
vra-chave, por nome de país, por uma data ou uma área de interesse específica.
O associado pode fazer também pesquisas por termos no Financial Dicionary, que o
remeterá para diversos links na Web.
Enfim, são muitos os benefícios e recursos disponibilizados no site da PRMIA.
Vale a pena se associar!
Web site
Para maiores detalhes acesse o Web site da PRMIA em http://www.prmia.org.
No Brasil, existe um Capítulo da PRMIA. Acesse o URL: http://www.prmia.org/
Chapter_Pages/Brazil/
IEEE COMPUTER SOCIETY

Introdução
Com aproximadamente 100.000 membros, a IEEE Computer Society é a maior or-
ganização de profissionais de computação. Fundada em 1946, é a maior das 39 socie-
dades do IEEE (Institute of Electrical and Electronics Engineers).
A visão da IEEE Computer Society é ser a líder no provimento de informações
técnicas, serviços para comunidade associada e serviços personalizados para os pro-
fissionais de computação do mundo.
A IEEE Computer Society é dedicada ao avanço da teoria, prática e aplicação do
computador e à tecnologia de processamento de informações. Através de suas confe-

CAPÍTULO 10 223
rências, publicações, jornais, capítulos locais e grupos de estudos, cursos à distância,

comitês técnicos e grupos de desenvolvimento de padrões, a IEEE Computer So-
ciety promove um intercâmbio ativo de informações, idéias e inovação tecnológica
entre seus associados. A IEEE Computer Society também trabalha em parceria com a
US Computing Sciences Accreditation Board and Accreditation Board for Enginee-
ring and Technology.
Com 40% de seus associados residindo e trabalhando fora dos Estados Unidos, a
IEEE Computer Society fomenta a comunicação internacional, cooperaração e troca
de informação. Para conveniência de seus associados, a IEEE Computer Society
mantém um escritório em Tóquio (Japão); um escritório de publicações em Los Ala-
mitos, California; e seu headquarter em Washington, DC.
Benefícios da associação
Dentre os benefícios de se associar a IEEE Computer Society destaco:
Informações técnicas
Assinatura complementar da Computer Magazine.
Acesso gratuito a 300 livros de TI.
Descontos em assinaturas de periódicos em sua área de expertise.
Tornar-se apto a assinar a Digital Library.
Descontos em taxas de registros nas conferências patrocinadas pelo IEEE.
Descontos em centenas de livros e publicações de conferências.
E-mail gratuito com o seu nome, exemplo: seu_nome@computer.org
Desenvolvimento de carreira
Acesso gratuito a 800 módulos de cursos de aprendizado à distância. Os assun-
tos incluem: Java, Cisco, Microsoft, gestão de projetos, segurança, e outros.
Descontos em exames de certificação e cursos de preparação para profissionais
de software.
Possibilidade de atuar como voluntário em projetos do IEEE Computer Society.
Torna-se apto para pleitear bolsas de estudos.
Networking
Associação gratuita em capítulos locais próximo de você.
Participação em até 4 dos 40 Comitês Técnicos.
Participar nos grupos de trabalho de padronização.
Livros disponíveis sobre gerenciamento de projetos de TI

Como associado você poderá ler via Web as seguintes publicações relacionadas ao as-
sunto deste livro:

IT Project Proposals: Writing to Win, by Paul Coombs (ed) ISBN:0521612578, Cambridge Uni-
versity Press, © 2005.
Information Systems Project Management: How to Deliver Function and Value in Information
Technology Projects, Second Edition by Jolyon Hallows ISBN:0814472737, AMACOM, ©
2005.
Complex IT Project Management: 16 Steps to Success, by Peter Schulte ISBN:0849319323, Auer-
bach Publications, © 2004.
90 Days to Launch: Internet Projects on Time and on Budget, by Shayne F. Gilbert ISBN:0471388262,
John Wiley & Sons, © 2001.
A Guide to the Project Management Body of Knowledge (PMBOK® Guide), 2000 Edition, by Pro-
ject Management Institute ISBN:1880410222, Project Management Institute, © 2000.
How to Run Successful High-Tech Project-Based Organizations, by Fergus O’Connell ISBN:1580530109,
Artech House, © 1999.
Cursos disponíveis no site do IEEE Computer Society para membros associados

Existem centenas de cursos que você pode fazer e acessar via Web, conforme classi-
ficados abaixo (os nomes foram mantidos em inglês).
BUSINESS STRATEGY
CISCO NETWORKS
DATABASES
DESKTOP
IP COMMUNICATIONS
LEADERSHIP
MANAGEMENT
OPERATING SYSTEMS
PROGRAMMING LANGUAGES
PROJECT MANAGEMENT
SECURITY
XML
BY CERTIFICATION
Business strategy
Competitive Intelligence
Implementing a Competitive Intelligence System
Analysis and Dissemination
Researching Online
International Business Essentials

The Global Business Environment
Conducting Business in Europe
Succeeding as a Global Manager

CAPÍTULO 10 225
Managing Business Risk

Developing a Risk Management Plan
Risk Assessment and Control
Financing and Contingency Planning
Strategic Management
Establishing Strategic Focus
Analyzing Strategic Options
Developing a Successful Process
Cisco Networks
Implementing CiscoWorks for Enterprise LAN/WAN Management
(CWENT) 1.0 (Network)
Cisco SAFE Implementation (CSI) 2.0 (CCSP)
Cisco SAFE Implementation (CSI) 1.1 (CCSP)
Cisco Secure IDS Host Sensor (CSIHS) 1.1
Cisco Secure Intrusion Detection System (CSIDS) 4.1 (CCSP)
Cisco Secure PIX Firewall Advanced (CSPFA) 3.2 (CCSP)
Cisco Secure Virtual Private Networks (CSVPN) 4.0 (CCSP)
Cisco Secure Virtual Private Networks (CSVPN) 3.1 (CCSP)
Designing Perimeter Security (DPS) 1.0 (CCSP)
Securing Cisco IOS Networks (SECUR) 1.1 (CCSP)
Building Scalable Cisco Internetworks (CCDP, CCNP)
Cisco Internetwork Troubleshooting (CCNP)
Databases
Microsoft SQL Server
Designing & Implementing Data Warehouses Using Microsoft SQL Server
7.0 (MCDBA, MCSE, MCSD)
Implementing a Database Design on Microsoft SQL Server 7.0 (MCDBA,
MCSE, MCSD)
Microsoft SQL Server 7.0 Data Warehousing
Microsoft SQL Server 7.0 Database Implementation (MCDBA, MCSD,
MCSE, MCSEINT)
Microsoft SQL Server 7.0 System Administration (MCDBA, MCSE, MCSEINT)
System Administration for Microsoft SQL Server 7.0 Curriculum (MCDBA,
MCSE)
Oracle
Oracle9i Database Fundamentals I (ORI9OCPDBA)
Oracle9i Database Fundamentals II (ORI9OCPDBA)

Oracle9i New Features: Backup, Recovery, and Performance Tuning

(ORA9IDBA)
Oracle9i New Features: Database Administration (ORA9IDBA)
Oracle9i Performance Tuning Curriculum (ORI9OCPDBA)
Oracle9i SQL Curriculum (ORI9OCPDBA)
Developer/2000: Build Forms I (OCP, ORACAD, ORADEV)
Developer/2000: Build Forms II (OCP, ORACAD, ORADEV)
Developer/2000: Build Reports (OCP, ORACAD, ORADEV)
Introduction to Oracle: SQL and PL/SQL Curriculum (Ver. III) (ORACAD,
ORADEV, ORC7DBA, ORC8DBA, ORC8IDBA, OCRCZINTAPD)
Oracle Develop PL/SQL Program Units Curriculum (V2) (OCP, ORACAD,
ORDEV, ORCZINTAPD)
Desktop
Microsoft Access 2003 Core Skills (MOS)
Microsoft Access 2003 Expert Skills (MOS)
Microsoft Excel 2003 Core Skills (MOS)
Microsoft Excel 2003 Expert Skills (MOS)
Microsoft Project 2003 Fundamentals
Microsoft Project 2003 Proficient User
IP Communications
IP Telephony Design (IPTD) 1.0 (IPT)
IP Telephony Troubleshooting (IPTT) 4.0 (IPT)
Leadership
Advanced Project Leadership
Organization, Strategy and Business Needs
Navigating Corporate Structures
Bringing Home the Value
Selling Project Management to the Organization
Project Leadership
Leading the Project Team
Communicating Within a Project Team
Overcoming Obstacles
Women in Leadership
Leadership Roles and Styles
Becoming A Leader
Developing a Leadership Path

CAPÍTULO 10 227
Frontline Leadership
Preparing to Lead
Knowledge in the Workplace
Positively Influencing Workplace Culture
Business Problem Solving

Problem Solving Fundamentals
The Problem-Solving Process
Critical Thinking and Information Analysis
Problem Solving Teams
Management
Effective Presentations
Planning a Presentation
The Presentation Process
Essentials of Persuasion
Communicating with Difficult People

Handling Difficult Co-Workers
Communicating with Your Manager
Working with Difficult Employees
Change Management
Adapting to Change
Managing Change
Managing Change
The Change Process
Overcoming Change Obstacles
Managing Yourself Through Change
Moving from Technical Professional to Manager

Getting Started
Managing Personnel
Managing the IT Department
Operating Systems
Linux Essentials Curriculum
Linux Technology Overview Curriculum
Introduction to UNIX 1.0

UNIX User Curriculum

Microsoft Systems Management Server 2.0 (MCSE)
Microsoft Windows 2000 Professional
Microsoft Windows Operating System Fundamentals (MCSE, MCSA)
Supporting Microsoft Windows 98 Curriculum (MCSE)
Microsoft Commerce Server 2000 Design and Implementation Curriculum
(MCSD)
Administering Microsoft Exchange Server 5.5 (MCSE)
Designing a Microsoft Exchange Server 2003 Organization (MCSA, MCSE)
Designing and Deploying a Messaging Infrastructure with Microsoft Exchan-
ge 2000 Server (MCSE)
Implementing and Managing Microsoft Exchange Server 2003 (MCSA,
MCSE)
Installing, Configuring and Administering Microsoft Exchange 2000 Server
(MCSE)
Microsoft Exchange Server 2003 Administration and Maintenance (MCSA,
MCSE)
Microsoft Exchange 2000 Server (MCSA, MCSE)
Supporting Microsoft Exchange Server 5.5 Curriculum (MCSE)
Microsoft ISA Server 2000 Curriculum (MCSE)
Introduction to Microsoft Project Server 2003 (MCSE)
Commerce Solutions with Microsoft Site Server 3.0 (MCSE)
Implementing Microsoft Site Server 3.0 (MCSE)
Microsoft Windows Server 2003

Implementing Security in Windows Server 2003 (MCSA, MCSE)
Active Directory and Network Infrastructure Design (MCSE)
Designing Security Curriculum (MCSE)
Environment Management and Maintenance (MCSE, MCSA, MCDBA)
Managing a Server Environment (MCSA, MCSD)
Managing Network Infrastructure (MCSA, MCSE)
Network Security Design (MCSE)
Network Services Management (MCSAS)
Skills Update for MCSAs (MCSA)
Updating Microsoft Windows 2000 MCSA Skills to Windows Server 2003
(MCSE, MCSA)
Updating Microsoft Windows 2000 MCSE Skills to Windows Server 2003
(MCSE)
Updating Microsoft Windows NT 4.0 MCSE Skills to Windows Server 2003
Administration Skills (MCSE, MCSA, MCDBA)

CAPÍTULO 10 229
Microsoft Windows 2000

Designing a Microsoft Windows 2000 Directory Services Infrastructure
(MCSE)
Designing a Microsoft Windows 2000 Networking Services Infrastructure
(MCSA, MCSE)
Designing Microsoft Windows 2000 Network Security (MCSA, MCSE)
Managing a Microsoft Windows 2000 Network Environment (MCSA,
MCSE)
Active Directory Design (MCSE)
Active Directory Implementation and Administration (MCSE)
Active Directory Services (MCSE)
Administration Curriculum (MCSE)
Clustering (MCSE)
Designing a Directory Services Infrastructure Curriculum (MCSE)
Designing a Network Infrastructure Curriculum (MCSE)
Designing Security Curriculum (MCSA, MCSE)
Directory Services Infrastructure Curriculum (MCSE)
Implementing Security Curriculum (MCSA, MCSE)
Installation, Configuration and Administration Curriculum (MCSE)
Network Infrastructure (MCSE)
Network Infrastructure Administration Curriculum (MCSE)
Network Infrastructure Design (MCSE)
Network Infrastructure Implementation and Administration (MCSA,
MCSE)
Network Management Curriculum (MCSA, MCSE)
Network Security Design (MCSA, MCSE)
Professional and Server Installation and Administration (MCSA, MCSE)
Server (MCSA, MCSE)
Upgrading from Microsoft NT 4.0 Curriculum (MCSE)
Administering Microsoft Windows NT 4.0 (MCSE)
Programming Languages
Mastering Microsoft Visual Basic 6.0 Development Curriculum (MCSD)
Microsoft Visual InterDev 6.0 Curriculum (MCSD)
Microsoft Visual Basic 5.0

Crystal Reports, DLLs, Add-Ins and MAPI (MCSD)
Error Handling, Testing & Distribution Issues (MCSD)
Programming Fundamentals (MCSD)
Working with ActiveX (MCSD)
Working with Databases (MCSD)

Java
Enterprise Connectivity with J2EE V1.4
JavaServer Pages and Servlets (JSP) 1.0
Java Database Connectivity (JDBC) 1.0
Java 2 Programming for SDK 1.4 Curriculum ( SUNCERT)
Java Programming Fundamentals (JFUN) 1.0
Sun Developer for the Java 2 Platform
Sun Programmer for the Java 2 Platform
Project management
Advanced Project Management (PMI)
Building Productive Stakeholder Relationships
Project Estimating Techniques
Managing Accelerated Projects
Setting Up a Project Office
Portfolio Management
Project Management Maturity
Managing IT Projects
Project Initiation and Fundamentals
Project Planning and Execution
Project Control and Closure
Project Management (3rd Edition) (PMI)

Project Management Framework
Project Management Processes
Project Integration Management
Project Scope Management
Project Time Management
Project Cost Management
Project Quality Management
Human Resource Management
Project Communications Management
Project Risk Management
Project Procurement Management
Project Management Essentials

Planning a Project
Project Scheduling and Budgeting
Controlling and Closing a Project

CAPÍTULO 10 231
Security
CompTIA Security+ 1.0 (Security+)
Security+ Curriculum (Security+)
Certified Information Systems Security Professional (CISSP) 1.0 (CISSP)
XML
Building XML-Based Web Applications
Introduction to XML 1.0
XML Programming Curriculum
By certification
MOS
Microsoft Access 2003 Core Skills
Microsoft Access 2003 Expert Skills
Microsoft Excel 2003 Core Skills
Microsoft Excel 2003 Expert Skills
CCSP
Cisco SAFE Implementation (CSI) 2.0
Cisco SAFE Implementation (CSI) 1.1
Cisco Secure Intrusion Detection System (CSIDS) 4.1
Cisco Secure PIX Firewall Advanced (CSPFA) 3.2
Cisco Secure Virtual Private Networks (CSVPN) 4.0
Cisco Secure Virtual Private Networks (CSVPN) 3.1
Designing Perimeter Security (DPS) 1.0
Securing Cisco IOS Networks (SECUR) 1.1
CCNP
Building Scalable Cisco Internetworks
Cisco Internetwork Troubleshooting
CCDP
Building Scalable Cisco Internetworks
Network
Implementing CiscoWorks for Enterprise LAN/WAN Management
(CWENT)1.0
MCDBA, MCSE, MCSD

Designing & Implementing Data Warehouses Using Microsoft SQL Server 7.0
Implementing a Database Design on Microsoft SQL Server 7.0

MCDBA, MCSD, MCSE, MCSEINT

Microsoft SQL Server 7.0 Database Implementation
MCDBA, MCSE, MCSEINT

Microsoft SQL Server 7.0 System Administration
MCDBA, MCSE
System Administration for Microsoft SQL Server 7.0 Curriculum
ORI9OCPDBA
Oracle9i Database Fundamentals I
Oracle9i Database Fundamentals II
ORA9IDBA
Oracle9i New Features: Backup, Recovery, and Performance Tuning
Oracle9i New Features: Database Administration
ORI9OCPDBA
Oracle9i Performance Tuning Curriculum
Oracle9i SQL Curriculum
OCP, ORACAD, ORADEV

Developer/2000: Build Forms I
Developer/2000: Build Forms II
Developer/2000: Build Reports
ORACAD, ORADEV, ORC7DBA, ORC8DBA, ORC8IDBA, OCRCZINTAPD

Introduction to Oracle: SQL and PL/SQL Curriculum (Ver. III)
OCP, ORACAD, ORDEV, ORCZINTAPD

Oracle Develop PL/SQL Program Units Curriculum (V2)
IPT
IP Telephony Design (IPTD) 1.0
IP Telephony Troubleshooting (IPTT) 4.0
Security+
CompTIA Security+ 1.0
Security+ Curriculum

CAPÍTULO 10 233
CISSP
Certified Information Systems Security Professional (CISSP) 1.0
MCSD
Mastering Microsoft Visual Basic 6.0 Development Curriculum
Microsoft Visual InterDev 6.0 Curriculum
Crystal Reports, DLLs, Add-Ins and MAPI
Error Handling, Testing & Distribution Issues
Programming Fundamentals
Working with ActiveX
Working with Databases
SUNCERT
Java 2 Programming for SDK 1.4 Curriculum
MCSE
Microsoft Systems Management Server 2.0
Microsoft Windows 2000 Professional
Supporting Microsoft Windows 98 Curriculum
Administering Microsoft Exchange Server 5.5
Designing and Deploying a Messaging Infrastructure with Microsoft Exchan-
ge 2000 Server
Installing, Configuring and Administering Microsoft Exchange 2000 Server
Supporting Microsoft Exchange Server 5.5 Curriculum
Microsoft ISA Server 2000 Curriculum
Introduction to Microsoft Project Server 2003
Commerce Solutions with Microsoft Site Server 3.0
Implementing Microsoft Site Server 3.0
Active Directory and Network Infrastructure Design
Designing Security Curriculum
Network Security Design
Updating Microsoft Windows 2000 MCSE Skills to Windows Server 2003
Designing a Microsoft Windows 2000 Directory Services Infrastructure
Active Directory Design
Active Directory Implementation and Administration
Active Directory Services
Administration Curriculum
Clustering
Designing a Directory Services Infrastructure Curriculum
Designing a Network Infrastructure Curriculum
Directory Services Infrastructure Curriculum

Installation, Configuration and Administration Curriculum

Network Infrastructure
Network Infrastructure Administration Curriculum
Network Infrastructure Design
Upgrading from Microsoft NT 4.0 Curriculum
Administering Microsoft Windows NT 4.0
MCSD
Microsoft Commerce Server 2000 Design and Implementation Curriculum
MCSA, MCSE
Microsoft Windows Operating System Fundamentals
Designing a Microsoft Exchange Server 2003 Organization
Implementing and Managing Microsoft Exchange Server 2003
Microsoft Exchange Server 2003 Administration and Maintenance
Microsoft Exchange 2000 Server
Implementing Security in Windows Server 2003
Managing Network Infrastructure
Updating Microsoft Windows 2000 MCSA Skills to Windows Server 2003
Designing a Microsoft Windows 2000 Networking Services Infrastructure
Designing Microsoft Windows 2000 Network Security
Managing a Microsoft Windows 2000 Network Environment
Designing Security Curriculum
Implementing Security Curriculum
Network Infrastructure Implementation and Administration
Network Management Curriculum
Network Security Design
Professional and Server Installation and Administration
Server
MCSA
Skills Update for MCSAs
MCSAS
Network Services Management
MCSA, MCSD
Managing a Server Environment
MCSE, MCSA, MCDBA
Environment Management and Maintenance
Updating Microsoft Windows NT 4.0 MCSE Skills to Windows Server 2003
Administration Skills

CAPÍTULO 10 235
Para ter acesso a um número maior de livros é necessário o pagamento de uma

taxa extra. Mais informações acesse: http://www.computer.org/bookshelf
Confira todos os benefícios no link: http://www.computer.org/portal/pages/
ieeecs/join/benefits.html
Web site e mais informações

No CD que acompanha este livro, na pasta \IEEE Computer Society\, você encon-
trará um arquivo chamado “APP06MEM.PDF”. Caso você se interesse pela associa-
ção, esta é a “Application” que deve ser preenchida e enviada para o IEEE Computer
Society. Os valores são válidos para o ano de 2006.
Você pode se associar também através do Web site da IEEE Computer Society,
preenchendo um formulário eletrônico e utilizando um cartão de crédito para efe-
tuar o pagamento.
Conforme vimos brevemente neste tópico, muitos recursos são disponibilizados
para o gerentes de projetos de TI através da associação na IEEE COmputer Society.
Vale a pena o investimento!
Mais informações sobre a IEEE Computer Socety poderão ser acessadas em seu
web site: www.computer.org
Endereço:
10662 Los Vaqueros Circle
P.O. Box 3014
Los Alamitos, CA 90720-1314 – USA
Tel: 1-714-821-8380
Fax: 1-714-821-4641
Conheça também o IEEE (Institute of Electrical and Electronics Engineers), aces-

se http://www.ieee.org/
ASQ – AMERICA SOCIETY FOR QUALITY

Introdução
A American Society for Quality (ASQ) é a autoridade líder mundial em qualidade.
Com mais de 100.000 membros (pessoas e organizações), essa associação profissio-
nal fomenta o avanço do aprendizado, melhoria da qualidade, troca de conhecimen-
tos para aprimorar os resultados dos negócios e a criação de melhores condições de
trabalho e comunidades em todo mundo.
Como campeã no movimento da qualidade, a ASQ oferece tecnologias, conceitos,
ferramentas e treinamento para os profissionais da qualidade e todos os consumidores.
Globalmente, a ASQ tem parcerias firmadas com organizações sem fins lucrativos
que compartilham suas missões e princípios. Seus esforços colaborativos vão ao en-
contro das necessidades das organizações e indivíduos no mundo todo.

Desde 1991 a ASQ administra o prêmio nacional dos Estados Unidos “Malcolm
Baldrige National Quality Award”, que anualmente reconhece as empresas que al-
cançaram excelência em performance.
Na área de TI, mais especificamente para o desenvolvimento de software, a ASQ
oferece uma certificação denominada “Certified Software Quality Engineer” – CSQE.
Para maiores informações sobre a certificação CSQE, acesse o “Software Quality
Engineer Certification Brochure” e o “Certified Software Quality Engineer Body of
Knowedge”, respectivamente, nos arquivos “csqe_brochure.pdf” e “csqe_bok.pdf”,
respectivamente na pasta \ASQ\ no CD que acompanha este livro. Além disso, con-
fira os arquivos “csqe-app-2006.pdf” e “csqe_sample_exam.pdf”, a aplicação para
prova e um exemplo de teste CSQE com 75 questões com gabarito (em inglês).
É possível fazer o download de todos os arquivos acima na site a ASQ.
Acesse também o site http://www.asq.org/certification/software-quality-engineer/
index.html.
Cursos preparatórios para o CSQE

Building Software Quality Skills
http://www.asq.org/courses/buildsoftwareq.html
Software Functional Testing
http://www.asq.org/courses/softwaretesting.html
Software Quality Engineering
http://www.asq.org/courses/softwareqe.html
Livros preparatórios para o exame

Fundamental Concepts for the Software Quality Engineer
http://qualitypress.asq.org/perl/catalog.cgi?item=H1115
Quality Audits for Improved Performance, 3a Edição
http://qualitypress.asq.org/perl/catalog.cgi?item=H1180
Quality Audit Handbook, 2a Edição: E-Book
http://qualitypress.asq.org/perl/catalog.cgi?item=E1046
Juran’s Quality Control Handbook, 5a Edição
http://qualitypress.asq.org/perl/catalog.cgi?item=P660
Lista de materiais de estudo para o exame CSQE

ANSI/ISO/ASQ Q9001-2000: Quality Management Systems: Requirements.
ANSI/ISO/IEETICKIT Guidelines.
Arter, Dennis, Quality Audits for Improved Performance, 3a Edição, Milwaukee: ASQC Quality Press,
2003.
Beizer, Boris, Black-Box Testing: Techniques for Functional Testing of Software and Systems, Nova York:
John Wiley & Sons, 1995. ISBN 0471120944.
Booch, Grady, James Rumbaugh, and Ivar Jacobson, The Unified Modeling Language User Guide, Addi-
son-Wesley, 1999. ISBN 0201571684.

CAPÍTULO 10 237
Booch, Grady, Objected-Oriented Analysis and Design with Applications, 2a Edição, Addison-Wesley Pu-
blishing Co., Inc., 1994. ISBN 0805353402.
Brassard, Michael e Diane Ritter, The Memory Jogger II: A Pocket Guide of Tools for Continuous Improve-
ment and Effective Planning, Goal/QPC, 1994.
Brooks, Frederick P. Jr., The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition,
Reading, Mass: Addison-Wesley Publishing Co., 1995. ISBN 0201835959.
Capability Maturity Model® Integration (CMMI), Version 1.1. CMMI for Systems Engineering,
Software Engineering, Integrated Product and Process Development, and Supplier Sourcing,
março de 2002.
Daughtrey, Taz, Edition, Fundamental Concepts for the Software Quality Engineer, ASQ Quality
Press, 2002.
Dunn, Robert H., e Richard S Ullman, TQM for Computer Software (System Design and Implementation)
2a Edição, McGraw Hill, 1994. ISBN 0070183147.
Fewster, Mark, e Dorothy Graham, Software Test Automation: Effective Use of Test Execution Tools, Grã
Bretanha: Addison-Wesley, 1999. ISBN 0201331403.
Freedman, Daniel, e Gerald M Weinberg, Handbook of Walkthroughs, Inspections, and Technical
Reviews: Evaluating Programs, Projects, and Products, 3a Edição, Nova York: Dorset House, 1990.
ISBN 0932633196.
Futrell, Robert T., Donald F. Shafer, e Linda I. Shafer, Quality Software Project Management, Upper
Saddle River, NJ: Prentice Hall, 2002. ISBN 0130912972.
Gilb, Tom, e Dorothy Graham, Software Inspection, Londres: Addison-Wesley Professional, 1993.
ISBN 0201631814.
Grady, Robert B, Practical Software Metrics for Project Management and Process Improvement, Englewood
Cliffs, Nova Jersey: Prentice Hall, 1992. ISBN 0137203845.
Gryna, Frank M., Quality Planning and Analysis: From Product Development through Use, 4a Edição, Nova
York: McGraw-Hill, 2001.
Hetzel, Bill, Complete Guide to Software Testing, 2a Edição, Wellesley, Mass: QED Information Scien-
ces, 1988. ISBN 0894352423.
Hetzel, Bill, Making Software Measurement Work, Boston, MA, QED Publishing Group, 1993. ISBN
0894354655.
Humphrey, Watts, A Discipline for Software Engineering, Reading, Mass: Addison-Wesley, 1995.
ISBN 0201546108.
Humphrey, Watts, Managing the Software Process, Reading, Mass: Addison-Wesley, 1989. ISBN
0201180952.
IEEE Standard 12207.0-1996: IEEE Standard for Industry Implementation of ISO/IEC 12207:1995.
ISO/IEC TR 15504-1998: Partes 1-9 Information Technology–Software Process Assessment.
Juran, Joseph M., Juran’s Quality Handbook, 5a Edição, Nova York: McGraw-Hill, 1999.
Kan, Stephen H., Metrics and Models in Software Quality Engineering, 2a Edição, Boston: Addi-
son-Wesley, 2003. ISBN 0201729156.
Kaner, Cem, Jack Falk, e Hung Quoc Nguyen, Testing Computer Software, Wiley Computer Publis-
hing, 1999. ISBN 0471358460.
Kerzner, Harold, PhD, Project Management: A Systems Approach to Planning, Scheduling, and Controlling,
8a Edição, Hoboken, Nova Jersey: John Wiley & Sons, Inc, 2003. ISBN 0471225770.
Kit, Edward, Software Testing in the Real World: Improving the Process, Addison-Wesley Publishing Co.,
1995. ISBN 0201877562.
Lyu, Michael R., Handbook of Software Reliability Engineering, Los Alamitos: IEEE Computer Society
Press, Nova York: McGraw-Hill, 1996. ISBN 0070394008. O livro está disponível on-line.
McConnell, Steve, Rapid Development: Taming Wild Software Schedules, Redmond, Wash: Microsoft
Press, 1996. ISBN 1556159005.

Myers, Glenford J., The Art of Software Testing, Nova York: John Wiley & Sons, 1979. ISBN
0471043281.
Nguyen, Hung, Testing Applications on the Web: Test Planning for Internet-Based Systems, Nova York: John Wi-
ley & Sons, Inc, 2001. ISBN 047139470X.
Paulk, Mark C., et al. The Capability Maturity Model–Guidelines for Improving the Software Process, Addi-
son-Wesley Publishing Co., 1995. ISBN 0201546647.
Pressman, Roger S., Software Engineering: A Practitioner’s Approach, 5a Edição, Nova York:
McGraw-Hill, 2000. ISBN 0072496681.
Rakitin, Steven R., Software Verification and Validation for Practitioners and Managers, 2a Edição, Boston:
Artech House, 2001. ISBN 1580532969.
Russell, J.P., ed., ASQ Quality Audit Division, The Quality Audit Handbook, 2a Edição, Milwaukee: ASQ
Quality Press, 2000.
Scholtes, Peter R., Brian L. Joiner, e Barbara J. Streibel, The Team Handbook, 3a Edição, Oreil Inc.,
2003.
Schulmeyer, G. Gordon, e James I. McManus, Handbook of Software Quality Assurance, 3a Edição,
Upper Saddle River, NJ: Prentice Hall, 1999.
SHRM – SOCIETY FOR HUMAN RESOURCE MANAGEMENT

Introdução
A Society for Human Resource Management (SHRM) – www.shrm.org – é uma das
maiores associações profissionais do mundo dedicada à gestão de recursos humanos.
Com mais de 200.000 membros, a missão da SHRM é atender às necessidades dos
profissionais de RH, fornecendo-lhes todos os recursos disponíveis para o avanço da
profissão e garantir que o RH seja reconhecido como um parceiro essencial no de-
senvolvimento e execução da estratégia organizacional. Fundado em 1948, a SHRM
atualmente possui 550 capítulos afiliados e membros em mais de 100 países.
Tipos de associações e taxas anuais

Existem quatro tipos de associações na SHRM.
Associate Membership. Ideal para as pessoas que se interessam pela gestão de re-
cursos humanos, mas que ainda não exercem nenhuma função relacionada.
Taxa anual: US$160.00.
Professional Membership. Para profissionais da área com pelo menos três anos de
experiência ou certificados pelo HRCI. Taxa anual: US$160.00.
General Membership. Indivíduos engajados na gestão de recursos humanos, en-
tretanto, sem o nível de proficiência exigido na associação Professional Members-
hip. Taxa anual: US$160.00.
Global Internet Membership. Específicos para indivíduos residentes em outros paí-
ses fora dos Estados Unidos. Todos os recursos e benefícios dessa associação são
disponibilizados via Web. Taxa anual: US$95.00

CAPÍTULO 10 239
Certificações para o profissional de RH

Existem três certificações reconhecidas internacionalmente para os profissionais de
RH; e que também se aplicam para os gerentes de projetos de TI e outras áreas:
PHR (Professional in Human Resources)
SPHR (Senior Professional in Human Resources)
GPHRTM (Global Professional in Human Resources)
A certificação é administrada pelo Human Resource Certification Institute (HRCI) –
http://www.hrci.org/.
Nas tabelas abaixo estão os valores das respectivas certificações (valor em US$).
PHR
Professional in Human Resources
Membros da SHRM US$ 250.00
Não-membros da SHRM US$ 300.00
Estudantes recém-formados US$ 120.00
SPHR
Senior Professional in Human Resources
GPHR
Global Professional in Human Resources
Estudantes recém-formados US$ 120.00
Os detalhes sobre as certificações da SHRM podem ser acessados no CD que

acompanha este livro, na pasta \SHRM\, o arquivo “2006 Certification Hand-
book.PDF”.
Vasto material de apoio e bibliografia também podem ser adquiridos no site
http://shrmstore.shrm.org/shrm/.
COMPTIA – THE COMPUTING TECHNOLOGY INDUSTRY ASSOCIATION

Introdução
A CompTIA é uma Associação da Indústria de Tecnologia de Computadores fundada
em 1982, com mais de 20.000 membros em 102 países. Dessa associação fazem par-
te organizações como a IBM, Hewlett Packard, Cisco, Xerox, entre outras.

Existe uma certificação específica para gerentes de projetos chamada CompTIA

Project+. O sinal de “+” no final do nome significa “Plus”.
A prova está dividida em quatro “domínios”, sendo:
Escope Definition (27% das questões);

Preliminary planning/Project planning (39% das questões);
Project Execution (29% das questões);
Closure (5% das questões).
Para os profissionais não gerentes de projetos existem outras certificações inte-

ressantes da CompTia, tais como A+, e-Biz+, Security+, CDIA+, HTI+, Linux+,
Server+, CTT+, i-Net+ e Network+.
Exemplos de questões
Você pode se inscrever no site da CompTIA gratuitamente para receber exemplos
de questões de todos os exames da CompTia no link: http://certification.comptia.
org/resources/practice_test.aspx. Chegando lá, preencha o formulário, selecione os
exames que lhe interessarem e clique no botão “Get Exam Objectives”.
Web site e contatos

Mais informações sobre a CompTIA: http:// www.comptia.org
As certificações da CompTIA podem ser acessadas no link: http://certification.
comptia.org/
Após se certificar, acesse o site http://itpro.comptia.org/.
Para tornar-se membro da CompTIA acesse http://members.comptia.org/.
Manuais preparatórios para as certificações editados pela própria CompTIA po-
dem ser encontrados no site https://store.comptia.org/
Os objetivos dos exames podem ser solicitados no link: http://certification.
comptia.org/resources/objectives.aspx
Dicas para realização dos exames podem ser acessadas no link: http://certifica-
tion.comptia.org/resources/test_tips.aspx
Preços dos exames para não-membros (referência junho de 2006)
CompTIA A+ Exam – US$153.00

CompTIA CDIA+, CTT (VBT), e-Biz+, Security+, RFID+ Exam Prices: –
US$237.00
CompTIA CTT+ (CBT), HTI+, i-Net+, Project+, Linux+, Network+, Server+
Exam Prices – US$218.00

CAPÍTULO 10 241
No Brasil a CompTIA pode ser contactada no seguinte endereço:

CompTIA Brazil (Public Policy Office)
Galan E Associates
WTC World Trade Center, Avenida das Nações Unidas, 12551, 9o ao 17o andar
São Paulo – Brasil
CEP: 04578-000
Tel: 11-3443-1518
Fax: 11-3943-1401
Email: galan@uol.com.br
Conclusão
As associações profissionais são fundamentais para o fomento da profissão de gerente
de projetos no Brasil e no mundo, pois disponibilizam muitos benefícios, recursos e
informações. Tornar-se um membro associado vai lhe trazer um diferencial no mer-
cado. E buscar a certificação vai lhe diferenciar ainda mais! É um investimento que
vale a pena!
Ressalto que a participação voluntária dos associados em projetos de criação de
novos padrões, por exemplo, é de vital importância para as associações. Seja entu-
siasta e esteja sempre disposto a ajudar. Todo mundo sai ganhando!
Não perca a oportunidade de fazer contatos com os profissionais de gerenciamen-
to de projetos, compartilhar informações e ajudar no fomento e na ampliação da cul-
tura de gerenciamento de projetos em nível mundial.
Associe-se! Venha fazer parte dessa comunhão de profissionais!

CAPÍTULO 11
Exemplos de softwares de
CONSIDERAÇÕES INICIAIS
Existem centenas ou talvez milhares de software que auxiliam no gerenciamento de
projetos, sejam eles corporativos, de médio ou de pequeno porte. E, a cada ano que
passa, mais aplicativos são lançados neste crescente mercado de gerenciamento de
projetos.
Neste capítulo, abordarei brevemente alguns desses aplicativos. Alguns já são co-
nhecidos dos usuários e outros estão sendo apresentados pela primeira vez para a Co-
munidade Brasileira de Tecnologia da Informação.
Serão abordados os seguintes aplicativos:
Task Tracking
WBS Chart Pro
PERT Chart EXPERT
MindManager 2002 Enterprise Edition
Microsoft Project 2002
Primavera TeamPlay
PMOffice
Open Project System (SAP)
Rational Project Management
PS8
Tassc Estimator Manager 2001

Spider Project
Palisade @RISK for Project
Kidasa Milestones Professional 2006
O objetivo deste capítulo não é induzir o leitor a comprar este ou aquele software,
mas apenas exemplificar a existência de tais produtos que muito auxiliam e agregam
valor ao gerente, ao gerenciamento de projetos e, principalmente, à organização.
Outro aspecto importante: também não farei comparações de funcionalidades
entre os aplicativos de fornecedores diferentes. Os aplicativos são apresentados iso-
ladamente em cada seção do capítulo, com alguns dos seus principais concorrentes
brevemente descritos. Todos os recursos aqui apresentados estão baseados nas infor-
mações dos Web sites dos respectivos fornecedores.
Também não serão fornecidas informações sobre os preços dos produtos, afinal,
podem sofrer alterações sem aviso prévio. Além disso, alguns produtos são vendidos
por módulos ou pela suíte completa e a precificação dependerá das necessidades de
cada cliente, seja este corporativo, de médio ou de pequeno porte.
Como consideração final, ressalto uma grande conquista tecnológica e de de-
monstração de capacidade técnica o fato de já existir no Brasil organizações que estão
desenvolvendo aplicativos em suas fábricas de software, auxiliando na integração
com produtos já utilizados no mercado e no gerenciamento de projetos de tecnolo-
gia da informação. Tais aplicativos utilizam o mesmo esquema de dados e se inte-
gram via API com outros aplicativos.
TASK TRACKING
Fabricante: Labtin
Site: www.logicway.com.br
O Task Tracking é um software nacional e fruto de um intenso trabalho de pesquisa,
desenvolvido por meus conterrâneos de Minas Gerais, em Uberlândia, o Laboratório
de Tecnologia da Informação.
Um dos grandes desafios da gerência de projeto é medir e avaliar a produtividade
dos recursos trabalhando em um projeto. Uma correta avaliação da produtividade
permite otimizar o cronograma, alocando os recursos corretos para cada tarefa, e
também possibilita o descarte de recursos que não são produtivos o suficiente.
A produtividade de cada recurso pode ser avaliada em parte analisando-se, por
exemplo, o tempo que um recurso gasta trabalhando em uma tarefa. Essa informa-
ção pode ser obtida através do cronograma, desde que o mesmo esteja atualizado
com a duração e o trabalho real da tarefa executada por um recurso.
Nem sempre é possível avaliar a produtividade de um recurso levando em consi-
deração somente as informações contidas no cronograma. No tempo de execução de
uma tarefa, podem estar embutidos momentos gastos com outras atividades concor-

EXEMPLOS DE SOFTWARES DE GERENCIAMENTO DE PROJETOS
CAPÍTULO 11 245
rentes, proporcionando uma produtividade falsa do recurso e, conseqüentemente, a

elaboração de cronogramas futuros menos realistas, baseados em informações histó-
ricas não totalmente confiáveis.
A suíte do Task Tracking é composta por três módulos: TT Cliente, TT Administra-
dor e TT Off-line, que podem auxiliar o gerente de projetos, concentrando-se nos re-
cursos. O uso desta suíte é essencial para implantar os conceitos básicos da gerência
de projetos e para ter uma administração mais eficiente no dia-a-dia dos projetos.
As empresas de tecnologia são o principal alvo dessa suíte. Essas empresas sentem
falta de uma ferramenta que forneça o status do andamento das tarefas em tempo real
e que esteja integrada às ferramentas de gerência de projetos já existentes.
Com o uso do TT, os gerentes responsáveis de cada projeto poderão ter informa-
ções atualizadas sobre o andamento de cada projeto. Essa administração se faz cada
vez mais necessária, pois projetos são investimentos em que cada dia de atraso repre-
senta algum tipo de prejuízo. A perda, nesse caso, pode ser tanto financeira, como de
desgaste com o cliente.
O Task Tracking utiliza um repositório centralizado, que é armazenado em um di-
retório compartilhado da rede. Com essa arquitetura, o TT é compatível com os
mais diversos sistemas operacionais disponíveis atualmente.
A Figura 11.1 ilustra a arquitetura do TT:
Gerente Recurso
MS Project TT Admin Rep. TT Cliente Off-line
Rep.
Remoto
F I G U R A 1 1 . 1 Arquitetura do Task Tracking
O funcionamento da suíte TT acompanha os seguintes passos:

O gerente cria um cronograma no MS-Project e utiliza o TT Administrador
para carregá-lo no repositório do TT.
Os recursos, utilizando o TT Cliente, podem visualizar as tarefas a eles atribuí-
das e podem atualizar o status das mesmas. O status atualizado é armazenado no
repositório TT.

Se os recursos não estiverem em contato direto com o repositório, ainda po-

dem trabalhar nas tarefas, utilizando o módulo TT-Offline.
O gerente pode, a qualquer momento, via TT Administrador, atualizar o cro-
nograma do MS-Project com as informações relacionadas às tarefas, obtendo
um quadro real dos progressos no projeto.
Dessa forma, o gerente pode estar sempre atualizado, monitorando o progres-
so de todos os recursos no projeto e identificando os atrasos no momento em
que eles acontecem, podendo tomar medidas corretivas de forma proativa.
A seguir, apresento mais detalhes sobre cada módulo da suíte.
TT Cliente
Este é o módulo no qual as tarefas definidas pelo gerente de projetos são apresentadas
aos recursos.
O TT Cliente permite aos recursos trabalharem nas tarefas e atualizá-las em tem-
po real.
O TT Cliente é protegido por um sistema de logon, permitindo o acesso apenas
para usuários cadastrados no repositório.
Atualização do cronograma
O TT permite que os recursos realizem várias operações sobre as tarefas existentes
no repositório, que são refletidas no cronograma sempre que o gerente desejar ver o
status do projeto. Dentre elas:
A duração da tarefa.
O trabalho na tarefa.
A criação de subtarefas.
A inserção de comentários na tarefa para, por exemplo, justificar o atraso na
tarefa.
A porcentagem concluída da tarefa.
A manutenção de um cronograma atualizado é essencial para a gerência de proje-

tos. Com os dados do cronograma, o gerente pode acompanhar o andamento do pro-
jeto, medir a produtividade dos recursos e utilizar esses dados na criação de crono-
gramas mais realistas.
Criação de subtarefas
O TT Cliente permite ao recurso subdividir uma tarefa complexa em tarefas com
complexidade menor. As novas tarefas criadas são visualizadas pelo gerente no cro-
nograma, permitindo um conhecimento melhor do andamento da tarefa e possibili-
tando no futuro a criação de tarefas similares, com diminuição de erros.
Se o gerente não aprovar a subdivisão, ele pode utilizar o MS-Project para remo-
ver as subtarefas e atualizar o repositório.

CAPÍTULO 11 247
Monitoramento
O TT Cliente permite que os recursos sejam monitorados sempre que estejam traba-
lhando em alguma tarefa. Esse monitoramento consiste na gravação de um log que
contém todos os aplicativos abertos e fechados durante a execução de uma tarefa.
Esse log pode ser visualizado pelo gerente no módulo TT Administrador.
O monitoramento auxilia na gestão da produtividade, pois permite visualizar
quais aplicativos foram utilizados por um recurso enquanto ele trabalhava em uma
tarefa. A produtividade do recurso pode ser analisada levando em consideração os
aplicativos abertos e o tempo trabalhado na tarefa.
O monitoramento também pode diminuir a dispersão do recurso na realização
das tarefas, porque o recurso sabe que está sendo monitorado e que a sua produtivi-
dade está sendo avaliada.
Aprendizado nas tarefas

No TT Cliente, o recurso pode informar as lições aprendidas em cada tarefa. Essas in-
formações podem ser visualizadas e analisadas pelo gerente no TT Administrador. São
informações preciosas que podem contribuir muito para o crescimento da equipe.
Com base nas lições aprendidas, o gerente pode também avaliar o nível de conhe-
cimento dos recursos em determinadas tarefas. Assim, em um próximo projeto,
tendo informações mais precisas sobre o nível de conhecimento dos recursos, o ge-
rente poderá alocá-los de forma mais eficiente.
TT Off-line
Em muitos casos, em projetos de desenvolvimento de software, por exemplo, os re-
cursos trabalham em um projeto off-site, ou seja, fora da sede da organização (no clien-
te), e conseqüentemente, não possuem acesso direto ao repositório TT. Para permitir
que mesmo esses recursos sejam controlados, foi projetado o módulo TT Off-line.
Esse módulo possui as mesmas funcionalidades que o TT Cliente, mas trabalha de
uma forma totalmente independente do repositório. O recurso pode utilizar o TT
Cliente para gerar um arquivo de trabalho que será usado pelo TT Off-line.
Assim que o recurso estiver mais uma vez em contato com o repositório, ele pode uti-
lizar o TT Cliente para ler o arquivo manipulado pelo TT Off-line e atualizar o repositó-
rio com todas as alterações realizadas no TT Offline, inclusive o log de monitoramento.
Dessa forma, o TT permite controlar a execução de tarefas remotamente, facilitan-
do a manutenção de cronogramas em que os recursos trabalham fisicamente distantes.
TT Administrador
Neste módulo o gerente de projetos pode manipular os usuários do sistema e suas
permissões, visualizar o log das operações efetuadas, do monitoramento e as lições
aprendidas.
O gerente também pode criar, desabilitar e remover projetos no TT Administrador.

Visualizar log de monitoramento dos recursos

No TT Administrador o gerente pode visualizar o log de monitoramento dos recur-
sos, que contém informações de todos os aplicativos abertos pelo recurso durante a
execução de tarefas do projeto. Esse log possibilita ao gerente de projeto analisar a
produtividade de cada recurso, além de possibilitar a verificação de quais aplicativos
foram mais utilizados na execução de determinadas tarefas. Isso permite ao gerente
disponibilizar somente os aplicativos necessários aos recursos na realização das tare-
fas, evitando dispersões.
Gestão de usuários
No TT Administrador o gerente pode inserir, remover, modificar usuários e senhas,
definindo também as permissões de acesso de cada usuário e as opções de segurança
do TT. Essas opções de segurança garantem a proteção do sistema de logon, evitando
que usuários não-cadastrados acessem os módulos do TT.
Gestão de projetos
No TT Administrador o gerente pode criar, alterar, desabilitar e remover projetos.
Todo projeto deve ser inicialmente criado no TT Administrador para posteriormen-
te ser visualizado e alterado no MS-Project.
O gerente pode utilizar todas as funcionalidades do MS-Project para manipular
projetos, dado que as alterações realizadas no projeto serão gravadas no repositório e
conseqüentemente visualizadas pelos recursos no TT Cliente. Apenas os projetos
são criados no TT Administrador. A criação de tarefas, o cálculo de datas e a manu-
tenção de calendários são realizados utilizando-se o MS-Project.
Conclusão sobre o Task Tracking

O conjunto de funcionalidades do Task Tracking possibilita a atualização freqüente
dos cronogramas de forma real.
O cronograma atualizado permite ao gerente acompanhar o andamento do proje-
to e controlar a data de término do projeto, observando o deadline (prazo final) e to-
das as variáveis existentes, podendo agir a tempo para corrigir qualquer problema
que seja detectado.
O TT também auxilia na gestão da produtividade, que permite ao gerente anali-
sar as performances dos recursos e, dessa forma, aprimorar (nivelar) as alocações
dos mesmos para cada tarefa e conseqüentemente a criação de cronogramas mais
realistas.
O Task Tracking demonstra a força e a qualidade de um software produzido na
América do Sul.

CAPÍTULO 11 249
WBS CHART PRO

Fabricante: Critical Tools
Web Site: www.criticaltools.com
WBS Chart Pro é um aplicativo específico para criação e exibição de WBS – Work
Breakdown Structure – mais conhecida aqui no Brasil como EAP (Estrutura Analíti-
ca do Projeto).
Uma WBS exibe a estrutura de um projeto mostrando como ele é organizado em
fases e em níveis de detalhes. Utilizar uma WBS é uma abordagem mais intuitiva de
se planejar e exibir um projeto.
A Figura 11.1 é um exemplo da tela principal do WBS Chart Pro:
F I G U R A 1 1 . 2 Janela principal do WBS Chart Pro
RECURSOS DO WBS CHART PRO

Cria atividades e fases com cliques, arrastar e soltar do mouse.
Cria WBS a partir de arquivos do Microsoft Project (Figuras 11.3 e 11.4).
Todas as alterações feitas no WBS Chart Pro são imediatamente refletidas no
Microsoft Project.
Exibe visões diferentes, do tipo planejamento de alto nível, ocultando outras
atividades.

F I G U R A 1 1 . 3 Exemplo no MS-Project
F I G U R A 1 1 . 4 Exemplo exportado para WBS Chart Pro

CAPÍTULO 11 251
F I G U R A 1 1 . 5 Exemplo de Visão Diferente
Pode-se expandir ou ocultar as atividades clicando nos sinais de “+” e “–”, res-
pectivamente.
Exibe um número ilimitado de campos.
Permite dar foco a uma determinada seção do projeto, onde você poderá visua-
lizar somente uma área específica e poderá também imprimi-la separada do
todo (Figuras 11.6 e 11.7).
Impressão em várias escalas.
Suporte a arquivo .MPX (abrir e salvar versões de arquivos-texto dos cronogra-
mas do Project).
Salva a WBS em páginas Web.
Salva a WBS como imagem.
Capacidade ilimitada do número de fases ou componentes da WBS.
Ajuste automático de quebra de página.
Suporta versões não-inglês do MS Project.
Compatível com o Project kickStart (mais informações sobre o Project KikStart,
acesse o URL: http://www.projectkickstart.com/).

F I G U R A 1 1 . 6 Exemplo de visão antes do foco
F I G U R A 1 1 . 7 Exemplo de visão depois do foco

CAPÍTULO 11 253
Requisitos do sistema
WBS Chart Pro é compatível com as versões Windows do Microsoft Project
4.1, 4.1a, Project 98, Project 2000 e Project 2002.
Sistema operacional: Microsoft Windows 95, Windows 98, Windows ME,
Windows NT, Windows 2000 e Windows XP.
Espaço em disco: 3 Mb.
Memória: 64 RAM.
PERT CHART EXPERT

Fabricante: Critical Tools
Site: www.criticaltools.com
PERT Chart EXPERT é um aplicativo utilizado especificamente para criar diagra-
mas PERT, também conhecidos como diagramas de rede, diagramas de precedência
ou diagramas lógicos.
Um diagrama PERT exibe as tarefas do projeto com suas dependências. Utilizar
um diagrama PERT é uma boa maneira de definir e exibir as relações de dependên-
cias que existem entre as tarefas.
Lembre-se de que a ordem na qual as tarefas ocorrem é parte importante do pla-
nejamento de um projeto, e os diagramas de PERT simplificam o processo de criar e
visualizar as dependências.
Recursos do PERT Chart EXPERT

Criação de diagramas PERT com cliques, arrastar e soltar do mouse.
Cria diagramas de rede a partir de arquivos do MS Project.
Calcula Caminho Crítico (Critical Path).
Interage com o Microsoft Project.
Contém calendários completos.
Agrupa as tarefas por recursos facilitando a visualização do diagrama e das rela-
ções de interdependência das atividades (Figura 11.8).
Agrupa as tarefas por fases, facilitando a visualização do diagrama e das relações
de interdependência das fases e atividades (Figura 11.9).
Exibe dependências ocultas (Figura 11.10).
Utiliza diagramas de PERT de dados filtrados. Por exemplo, utilizando os
filtros do Project, você exibirá somente um subconjunto de informações (Figu-
ra 11.11).
Você pode aplicar também filtros do tipo Caminho Crítico (Figura 11.12).
Exibe a linhas de dependências entre as atividades (Figura 11.13).

F I G U R A 1 1 . 8 Agrupamento por recursos
F I G U R A 1 1 . 9 Agrupamento por fases

CAPÍTULO 11 255
F I G U R A 1 1 . 1 0 Exibição de dependências ocultas
F I G U R A 1 1 . 1 1 Dados filtrados

F I G U R A 1 1 . 1 2 Dados filtrados Caminho Crítico
F I G U R A 1 1 . 1 3 Linhas de dependências

CAPÍTULO 11 257
Traça o caminho das atividades e suas dependências em todo o diagrama.

Cria diagramas de rede com diferentes escalas de tempo (dia, semana, mês, tri-
mestre, ano etc.)
A Figura 11.14 mostra um exemplo do recurso com escala de tempo.

A Figura 11.15 mostra um exemplo sem escala de tempo.
Capacidade ilimitada de número de campos por atividade (Figura 11.16).

Impressão em várias escalas.
Suporte a arquivos .MPX (abrir e salvar versões de arquivos-texto dos crono-
gramas do Project)
Salva em páginas Web.
Salva como imagem.
Ajuste automático de quebra de página.
Suporta versões não-inglês do MS Project.
F I G U R A 1 1 . 1 4 Exibição com escala de tempo

F I G U R A 1 1 . 1 5 Exibição sem escala de tempo
F I G U R A 1 1 . 1 6 Campos ilimitados

CAPÍTULO 11 259
WBS Chart Pro é compatível com as versões Windows do Microsoft Project
4.1, 4.1a, Project 98, Project 2000 e Project 2002.
Sistema operacional: Microsoft Windows 95, Windows 98, Windows ME,
Windows NT, Windows 2000 e Windows XP.
Espaço em disco: 3 Mb.
Memória: 64 RAM.
MINDMANAGER
Fabricante: MindJet
Site: www.mindjet.com
Mapas são uma forma poderosa de planejar e comunicar o conhecimento. Utiliza-
mos palavras e dicas visuais (proximidade, cores, gráficos e ícones) para expressar
atividades, processos e relacionamentos. Os mapas permitem informar em um ins-
tante o que documentos levariam várias páginas de texto para expressar. É mais ou
menos aquela velha história: uma imagem vale mais do que mil palavras.
O MindManager é uma ferramenta que ajuda a mapear os processos de planejamen-
to do projeto, conduzir reuniões e promover seções de brainstorming (Figura 11.17).
F I G U R A 1 1 . 1 7 Tela principal do MindManager

Seções tradicionais de brainstorming normalmente envolvem quatro procedi-

mentos:
1. Capturar idéias no flip chart ou na lousa.
2. Transcrever anotações (nem sempre muito legíveis) para o formato eletrô-
nico.
3. Organizar as anotações (é inevitável esquecermos as relações-chave de idéias).
4. Distribuir as informações impressas ou via e-mail.
Tempo e recursos são desperdiçados remontando as informações, e os membros
da equipe do projeto têm uma diferente compreensão dos resultados das reuniões.
O MindManager ajuda nos processos de brainstorming, mantendo todos concen-
trados na mesma tela, e elimina os retrabalhos desnecessários em dois passos:
1. Captura e organiza as idéias na hora em que elas surgem num formato visual,
promovendo uma maior interatividade do time e maior contribuição indivi-
dual.
2. Permite distribuição imediata das anotações das reuniões.
Benefícios
Melhora a colaboração.
Ajuda a capturar e maximizar idéias, conduzindo para projetos que são clara-
mente definidos, mais lucrativos e entregues mais rapidamente.
Melhora
Colaboração
Captura
Idéias
Aceita
Projetos
Aumenta
Benefícios Taxa de
do Produto Sucesso
Garante
a
Transparência
Toma
Decisões
Aumenta a Mais
Produtividade Inteligentes
da Equipe
F I G U R A 1 1 . 1 8 Arquitetura dos benefícios

CAPÍTULO 11 261
Aumenta a produtividade do time do projeto.

Garante a transparência.
Economiza tempo precioso.
Aumenta a participação e a moral do time de projeto.
Integra-se com os seguintes aplicativos da família Microsoft Office: Project,
Word, Outlook, PowerPoint.
Um Pequeno Tour pelo Produto

Esta seção se divide em Brainstorming, Reuniões e Planejamento.
Brainstorming
Comece com um conceito (Figura 11.19). Então, faça um brainstorming das idéias
com os membros do projeto:
F I G U R A 1 1 . 1 9 Conceito
Como aumentar
a satisfação
do cliente?
O resultado é um mapa que contém um conjunto de idéias prontas para serem

avaliadas, organizadas e priorizadas (Figura 11.20).
A Figura 11.21 mostra o exemplo de um mapa de uma seção de brainstorming que
foi reorganizado e melhorado.
Reuniões
Use um mapa como agenda de reunião para garantir que todos os aspectos pertinen-
tes estarão presentes: mapas ajudam manter o foco da reunião e facilitam o consenso
das decisões.
Planejamento
Você pode ir mapeando as tarefas de um projeto (Figura 11.23). Os recursos de pla-
nejamento do MindManager permitem definir e priorizar as tarefas (Figura 11.24).
Recursos Principais
Compatível com o VBA script para customizar funcionalidades.
Suporte a Thin client: Windows Terminal Server e Citrix.
Robustos recursos de segurança para o servidor de conferência.

Manual amigável do usuário
Melhorar a durabilidade
Criar o web site do produto
Mais fácil de usar

Operação silenciosa
Melhor serviço
Como aumentar Forma e cores atrativas
a satisfação
Forma compacta do cliente?
Pacotes reutilizáveis
Desligar automaticamente
Multiusuário
Mais leve
Melhor segurança
Recursos convenientes
F I G U R A 1 1 . 2 0 Resultado do mapa
Desligar computadores
e impressoras todas as noites
Reutilizar envelopes
Energia Aumentar a temperatura
Embalagens reutilizáveis do escritório aos poucos
Fornecedores
Calculadoras solares Equipamentos novos devem
ter controle de energia
Cartuchos recicláveis
Esboço ou rascunhos somente
Brainstorming na tela-sem impressão
Como reduzir
o desperdício Papel Configurar impressora para
rascunhos com papel reciclado
no escritório?
Ser pontual e estar sempre Utiliza os dois lados do papel
preparado para reuniões para impressão quando possível
Alocar atividades específicas
para recursos com tais habilidades
Manter-se concentrado nas discussões Tempo
Toalhas reutilizáveis
Ser cuidadoso para Sala de espera
aumentar a eficiência Talheres e utensílios laváveis
Quando compor um e-mail

seja claro e objetivo
F I G U R A 1 1 . 2 1 Mapa melhorado

CAPÍTULO 11 263
Falta de recursos necessários

Trava freqüentemente
Muito lento
Contras Curva de aprendizado Interface antiga

Não intuitiva
Sistema Atual
Difícil de fazer backup e mesclar
dados em diversos locais
Não permite uso remoto
Nós já sabemos como utilizá-lo
Prós Sem despesas (custos)
S Interface simples
VOTO:
N Atualização Recursos necessários Autocompletar
Voto de Software Funções de busca
Outro de Banco de Dados
Mais confiável
Ausente Maior velocidade =
Prós
maior eficiência
Backup automático
Novo Sistema Usa banco de dados centralizado
Interface Web permite acesso
de qualquer lugar
Todos teremos de aprender a utilizá-lo
Contras Custa 149 dólares por usuário

Sacrifica a simplicidade
F I G U R A 1 1 . 2 2 Mapa de reunião
Análise competitiva e complementar

do produto
3 dias
Pesquisa Etinográfica
5 dias
PESQUISA DE DESCOBRIMENTO
Perguntas contextuais
3 dias
Análise de tarefas
2 dias
Estudo seqüencial
2 dias
Biomecânica
10 dias
PESQUISA DE
DESENVOLVIMENTO: Conhecimento
AVALIAÇÃO DE ERGONOMIA
ESTIMATIVAS
2 dias
DE TAREFAS
Antropométrico
1 dia
Teste de preferência
1 dia
TESTES DE USUÁRIO
Teste de usabilidade
3 dias
F I G U R A 1 1 . 2 3 Mapa de planejamento

Desenvolver o relatório Reunir-se com cliente

AVALIAÇÃO
Reunião de equipe 10/29 : 10/29
3/3 : 3/4 R: Liason
Preparar demonstração
10/30 : 11/7
Quadro de colaboração R: Liason
12/2 : 12/6 Plano preliminar do projeto
Desenvolver protótipo 10/30 : 11/4
12/9 : 12/27 R: Project Mgr
R: Liason Plano de informação
Revisão de protótipo PLANEJAMENTO 11/5 : 11/7
12/30 : 1/3 R: Developer
R: All Plano Espec. de conteúdo
Testes de usabilidade 11/7 : 11/15
1/8 : 1/10 DESENVOLVIMENTO
R: Writer
R: Agency DO Plano de revisões
Modificações WEB SITE 11/18 : 11/18
1/13 : 1/17 R: All
R: Developer
Protótipo atual IMPLEMENTAÇÃO Finalizar planos
1/20 : 1/20 11/18 : 11/27
R: Liason R: All
Revisão de Cliente
1/20 : 1/28
R: none
Finalizar site
1/29 : 2/7
R: Devel...
Verificar site
2/8 : 2/9
R: Devel...
Entregar site
2/10 : 2/10
R: Liason
F I G U R A 1 1 . 2 4 Definição e priorização de tarefas
Modo de apresentação para exibir mapas em tela cheia.

Assistentes (Wizards) intuitivos, Templates, Legenda Dinâmica.
Exporta para Web com HTML templates.
Sincroniza com PDAs utilizando o MindManager Mobile Edition.
Sistemas Operacionais: Windows® 95, 98, Me, NT 4.0 (com Service Pack 6),
Windows 2000 e Windows XP.
Processador: Pentium 133 ou superior.
Memória: 48MB RAM ou superior.
20MB espaço em disco, 30MB adicionais para os símbolos.
Monitor Super VGA (800x600) resolução superior, 256 cores ou mais.
Requisitos para o Conference Server System

Windows NT 4.0, Windows 2000 Professional ou superior.
No mínimo 128MB RAM (256MB recomendado).
Processador: Pentium III 600MHz (800MHz recomendado).
Monitor: Super VGA.

CAPÍTULO 11 265
HD de 45 MB ou superior.
CD-ROM.
Duas placas de rede.
Endereço IP Dedicado.
Um HTTP Server – porta 80 é padrão (default).
Internet Explorer 5.0 ou superior para administração do servidor.
Idiomas
A interface do produto está disponível em quatro idiomas:
inglês
alemão
italiano
francês
Novos recursos do Mindjet MindManager Pro 6:

Com mais de 20 novos recursos, o Mindjet MindManager Pro 6 irá ajudar ainda mais
as equipes a finalizar rapidamente seus projetos empresariais. Adicione opções pode-
rosas de integração e gerenciamento de dados e você terá o melhor software já de-
senvolvido pela Mindjet.
Simplificação dos fundamentos
Novas funcionalidades de mapeamento.
Edição e visualização outline
Edite mapas em outline tão bem quanto a visualização tradicional de mapea-
mento.
Tópicos de memória temporária (Rollover)
Setas e esboços outlines indicam quando você pode expandir ou contrair os tó-
picos para exibir ou ocultar as informações detalhadas.
Barra de menu
Menus adicionais foram desenvolvidos para fornecer recursos extras.
Organograma
Visualize, rapidamente, a estrutura de sua equipe.
Gerencie os dados e as informações de forma efetiva
O Mindjet MindManager Pro 6 torna fácil a tarefa de buscar informações e dei-
xá-las reunidas.
Gráficos e planilhas eletrônicas
Insira planilhas eletrônicas em um tópico para capturar dados numéricos, exe-
cute cálculos e faça gráficos com os resultados.
Insira anexos
Insira múltiplos arquivos em um único tópico, tendo assim um acesso rápido e
uma fácil comunicação

Distribuição dos mapas

Redistribua, simetricamente, os Tópicos de um mapa ao redor do Tópico central.
Numeração dos Tópicos
Adicione números seqüenciais em seus tópicos.
Comunicação visual
Comunique-se de forma clara com um conjunto aperfeiçoado de ferramentas visuais.
Novos padrões de estilo e de modelos
Crie mapas visualmente profissionais com os novos estilos para Tópicos, como
bordas, fundos e muito mais.
Barra com ferramentas avançadas de formatação
Adicione opções avançadas de formatação como estilos de linha, Tópico ajustá-
vel e alinhamento.
Gere facilmente novas informações
Trabalhe mais rapidamente gerando informações no Mindjet MindManager
Pro 6 e utilize-as em um host a partir de outras aplicações.
Exportação aperfeiçoada para o Microsoft PowerPoint
Exporte de forma eficiente os dados do Mindjet Mindmanager Pro 6 para o Mi-
crosoft PowerPoint.
Microsoft Visio
Crie processos em diagramas e exporte o conteúdo do mapa para o Microsoft
Visio.
Microsoft Excel
Adicione links nas planilhas de dados do Microsoft Excel para uma atualização mais
rápida. As alterações nas planilhas serão automaticamente refletidas no mapa.
Microsoft Internet Explorer
Adicione facilmente um link entre uma página da Web e o seu mapa, por meio
de um ícone do Mindjet MindManager Pro 6 que fica na barra de ferramentas
do Internet Explorer.
Colabore
Trabalhe de forma efetiva com seus colegas e com a sua equipe.
Poderosos filtros de seleção
Filtre e selecione somente os Tópicos com as informações pertinentes ou que
tenham critérios específicos.
Tópicos de aviso
Defina avisos para serem ativados quando uma ação é requerida em um Tópico.
O alerta aparecerá até mesmo se o mapa estiver fechado.
Modo de revisão
Rastreie as mudanças realizadas no Tópico. Use a nova barra de Revisão para
aceitar ou rejeitar a edição do Tópico.
Cronômetro
Mantenha um relógio para marcar o tempo das reuniões que foram agendadas.

CAPÍTULO 11 267
MICROSOFT PROJECT 2002

Fabricante: Microsoft
Web Site: http://www.microsoft.com/brasil/project/default.asp
Recentemente, a Microsoft lançou uma nova versão do Microsoft Project. Para faci-
litar o entendimento destas mudanças, apresentarei as informações conforme a se-
guinte ordem:
Perguntas e respostas
Benefícios de migração
Benefícios do Microsoft Project Server
Quadro comparativo entre as versões do Microsoft Project
Perguntas e respostas
Quais são as novidades do Microsoft Project 2002?

O Microsoft Project 2002 inclui vários novos recursos e algumas melhorias muito
significativas. Essas inovações se situam principalmente em três áreas:
Os recursos do Microsoft Project 2002 tornaram-se mais intuitivos.
Os dados sobre projetos estão mais acessíveis, facilitando a colaboração entre
os integrantes de equipes de projetos.
As empresas podem utilizar uma plataforma de gerenciamento de projetos cor-
porativos.
Quais foram as mudanças feitas no Microsoft Project?
O Microsoft Project foi ampliado para incluir as seguintes versões e combinações do
produto:
Microsoft Project Standard 2002, a nova versão do gerenciador de projetos do
Office.
Microsoft Project Professional 2002, o novo gerenciador de projetos do Offi-
ce, previsto para ser usado em conjunto com o Microsoft Project Server 2002,
como a solução Microsoft para o Gerenciamento Corporativo de Projetos ou o
produto integrado Enterprise Project Management.
Microsoft Project Server 2002, o novo servidor corporativo pertencente ao
grupo de Enterprise Servers da plataforma Microsoft .NET. O produto foi pro-
jetado para trabalhar em conjunto com o Microsoft Project. O Microsoft Pro-
ject Web Access é a interface Web do Microsoft Project Server, destinado a
usuários que não necessitam de todos os recursos necessários ao acompanha-
mento de projetos inerentes ao Microsoft Project.
Microsoft Project Server Client Access License (CAL) é uma licença que auto-
riza o usuário a utilizar os recursos e tecnologias do Microsoft Project Server,
incluindo o Microsoft Project Web Access.

Quais são as principais diferenças entre o Microsoft Project 2002 Standard

e o Microsoft Project Professional 2002?
O Microsoft Project Standard ainda é o produto de controle de projetos para geren-
tes de projetos, gerentes de negócios e profissionais de planejamento e de gerencia-
mento de projetos em suas estações de trabalho.
Já o Microsoft Project Professional é o programa de gerenciamento de projetos
que pode ser usado com o Microsoft Project Server 2002 (em conjunto com as licen-
ças de acesso Microsoft Project Server CALs) como parte da solução completa
Enterprise Project Management. O Microsoft Project Professional oferece as prin-
cipais ferramentas contidas no Microsoft Project Standard, além de recursos para o
gerenciamento de projetos corporativos.
O que é o Microsoft Project Server?

O Microsoft Project Server 2002 é um novo produto que integra a família de servi-
dores .NET Enterprise Servers. O produto, quando usado em conjunto com o Mi-
crosoft Project, oferece uma plataforma para a colaboração de grupos de trabalho e
para o gerenciamento de projetos corporativos.
Pode-se usar o Microsoft Project Server para armazenar, de forma centralizada,
projetos e informações sobre recursos. O Microsoft Project Server permite que sejam
compartilhadas informações on-line com toda a equipe do projeto, de forma centrali-
zada, para otimizar os recursos. Ele permite ainda padronizar os relatórios de projetos
e promover a modelagem de grupos de projetos baseada em cenários e análises.
O que é o Microsoft SharePoint Team Server?

SharePointTM Team Services da Microsoft é uma solução de um Web site que acompanha
o Microsoft Project Server 2002, voltado para agilizar a troca de informações de uma
equipe de projeto. O SharePoint Team Services trabalha de forma totalmente integrada
ao Microsoft Project Server 2002, permitindo que as equipes armazenem os projetos em
uma central Web e organizem todos os documentos pertinentes ao projeto utilizando o
Microsoft Project Web Access, a interface Web do Microsoft Project Server.
O que é o Microsoft Project Web Access?

O Microsoft Project Web Access é um recurso do Microsoft Project Server 2002. Tra-
ta-se da interface baseada no browser Web que os integrantes da equipe de projetos
podem utilizar para acessar e atualizar informações armazenadas no Microsoft Project
Server – sem que tenham de instalar o Microsoft Project em seu computador.
Para utilizar o Microsoft Project Web Access, o usuário deverá ter uma licença de
acesso Microsoft Project Server CAL. Essa licença é necessária para a utilização dos servi-
ços ou funcionalidades do Microsoft Project Server. Não se trata de um produto de soft-
ware, apenas de uma licença que cada participante do projeto que utiliza o Microsoft
Project Web Access necessita ter para poder acessar as informações desse projeto.

CAPÍTULO 11 269
Como funciona o Microsoft Project junto com o Microsoft Project Server?

O Microsoft Project Professional traz os recursos corporativos necessários para a
criação e gerenciamento de planejamentos, projetos e publicação das respectivas in-
formações no Microsoft Project Server.
Junto com o Microsoft Project Server 2002 e as licenças de acesso Microsoft Pro-
ject Server CALs, o Microsoft Project Professional é parte integrante da solução
Enterprise Project Management da Microsoft. Essa abrangente solução permite que
as equipes de projetos realizem as seguintes atividades:
Colaboração e compartilhamento de informações

Gerenciamento centralizado de recursos e projetos
Geração padronizada de relatórios
Integração dos sistemas internos no Microsoft Project
O que aconteceu com o Microsoft Central Server?

O Microsoft Project Central Server, que acompanhava o Microsoft Project 2000, foi
substituído pelo Microsoft Project Server 2002. Ao contrário do Microsoft Project
Central Server, o Microsoft Project Server 2002 deverá ser adquirido separadamente.
Quando utilizado em conjunto com o Microsoft Project, o Microsoft Project Ser-
ver 2002 suporta todas as funções de colaboração que estavam incluídas no Microsoft
Project Central, tais como cronogramas de tempo, relatórios de status e exibições
do projeto.
Além disso, os recursos de colaboração do Microsoft Project Server 2002, depois
de sua integração do SharePoint Team Services, sofreram uma sensível melhora,
pois agora é possível utilizar o SharePoint Team Services para armazenar, centraliza-
damente, documentos e informações relativas ao projeto. É possível também com-
binar o Microsoft Project Server com o Microsoft Project Professional para adquirir
os recursos de gerenciamento corporativo de projetos.
Em quais idiomas está disponível o Microsoft Project?

O Microsoft Project Standard 2002 e o Microsoft Project Server 2002 estão disponí-
veis em 19 idiomas, todos com o mesmo formato de arquivo. Os idiomas são: ale-
mão, chinês (simplificado), chinês (tradicional), coreano, dinamarquês, espanhol,
finlandês, francês, hebraico (habilitado), holandês, inglês, italiano, japonês, norue-
guês (Bokmal), polonês, português, russo, sueco e tcheco.
O Microsoft Project Professional 2002 está disponível em nove idiomas: chinês
(tradicional), inglês, francês, alemão, italiano, japonês, coreano, português (Brasil)
e espanhol.

Microsoft Project Standard 2002

A configuração de sistema recomendada para o Microsoft Project Standard 2002 é
um computador com processador Pentium III e 192 MB de RAM, rodando sob o sis-
tema operacional Microsoft Windows® XP Professional.
Requisitos Mínimos
Computador/ PC com processador Pentium de 133-megahertz (MHz) ou
Processador superior.
Sistema Windows 98, Windows 98 Second Edition, Windows Mil-
Operacional lennium Edition (Windows Me), Microsoft Windows NT®
versão 4.0 com o Service Pack 6 (SP6) ou posterior, Win-
dows 2000 Professional ou Windows XP Professional.
Memória Os requisitos de RAM dependem do sistema operacional em uso:
Windows 98 ou Windows 98 Second Edition:
24 MB de RAM mais 32 MB de RAM adicionais para o
Microsoft Project.
Windows Me ou Windows NT:
Microsoft Project.
Windows 2000 Professional:
Microsoft Project.
Windows XP Professional:
Microsoft Project.
Disco Rígido Os requisitos de espaço no disco rígido dependem da configu-
ração; algumas configurações especiais de instalação persona-
lizada podem demandar mais ou menos espaço no disco rígi-
do. A seguir, os requisitos mínimos de espaço no disco rígido
para o Microsoft Project:
105 MB de espaço livre no disco rígido,* além de 70 MB
de espaço onde está instalado o sistema operacional.
*Os usuários que não têm o Windows XP, Windows
2000, Windows Me, Office XP, Office 2000 Service
Release 1 (SR-1) ou o Microsoft Project 2000 necessi-
tam de 50 MB de espaço adicional no disco rígido para a
Atualização de Arquivos do Sistema.

CAPÍTULO 11 271
Drive Drive CD-ROM.

Monitor de vídeo Monitor Super VGA (800 × 600) ou resolução superior, de
256 cores.
Mouse Microsoft Mouse, Microsoft IntelliMouse® ou dispositivo
apontador compatível.
Programas Microsoft Internet Explorer 5.01 ou superior (recomendado
o Internet Explorer 5.5).
Microsoft Project Professional 2002

A configuração de sistema recomendada para o Microsoft Project Professional 2002
é um computador com processador Pentium III e 256 MB de RAM, rodando sob o
sistema operacional Microsoft Windows® XP Professional.
Requisitos mínimos
Computador/ PC com processador Pentium de 133-megahertz (MHz) ou su-
Processador perior.
Sistema Windows 98, Windows 98 Second Edition, Windows Millen-
Operacional nium Edition (Windows Me), Microsoft Windows NT® ver-
são 4.0 com o Service Pack 6 (SP6) ou posterior, Windows
2000 Professional ou Windows XP Professional.
Memória Os requisitos de RAM dependem do sistema operacional em uso:
24 MB de RAM mais 48 MB de RAM adicionais para o Mi-
crosoft Project.
crosoft Project.
crosoft Project.
Microsoft Project.
ração; algumas configurações especiais de instalação personali-
zada podem demandar mais ou menos espaço no disco rígido.
A seguir, os requisitos mínimos de espaço no disco rígido para
o Microsoft Project:

105 MB de espaço livre no disco rígido*, além de 70 MB

no espaço onde está instalado o sistema operacional.
Os usuários que não têm o Windows XP, Windows
2000, Windows Me, Office XP, Office 2000 Service Re-
lease 1 (SR-1) ou o Microsoft Project 2000 necessitam de
50 MB de espaço adicional no dispo rígido para a atualiza-
ção de arquivos do sistema.
*Necessários 55 MB para uma instalação típica em um sis-
tema que tenha instalado o Office XP; 310 MB para uma
instalação completa em um computador que não tenha o
Office XP instalado.
Drive Drive CD-ROM.
256 cores.
Mouse Microsoft Mouse, Microsoft IntelliMouse® ou dispositivo
apontador compatível.
Programas Microsoft Internet Explorer 5.01 ou superior (recomendado o
Internet Explorer 5.5).
Microsoft Project Server 2002

A configuração de sistema recomendada para o Microsoft Project Server 2002 é um
computador com processador Pentium III de 700 MHz (megahertz) e 512 MB de
RAM, rodando sob o sistema operacional Microsoft Windows® 2000 Server.
Obs: O Microsoft Project Server 2002 foi projetado para trabalhar em conjunto
com o Microsoft Project 2002.
Requisitos mínimos
Computador/ Computador com processador Pentium III de 500-MHz ou su-
Processador perior.
Sistema Windows 2000 Server com o Service Pack 1 (SP1) ou superior,
Operacional ou Windows 2000 Advanced Server com o SP1 ou superior.
Memória* Os requisitos de RAM dependem dos serviços instalados no
computador. A seguir, os requisitos mínimos de RAM para o
Microsoft Project Server:
*O tipo de processador, a memória RAM e os requisitos do disco rígido dependem diretamente da quan-
tidade de serviços instalados no computador. Os requisitos mínimos presumem que apenas os componen-
tes do Microsoft Project Server sejam instalados (isso significa que o SharePoint Team Services, o SQL
Server e outros serviços serão executados em outros computadores).

CAPÍTULO 11 273
128 MB de RAM (recomendados 512 MB).

Os clientes que instalarem o SharePointTM Team Ser-
vices da Microsoft terão de dispor de um mínimo de
128 MB de RAM adicionais (recomendados 192 MB
adicionais).
Os clientes que instalarem o Microsoft SQL ServerTM
2000 terão de dispor de um mínimo de 64 MB de RAM
adicionais (recomendados 128 MB adicionais).
Os clientes que instalarem o SQL Server Analysis Servi-
ces terão de dispor de um mínimo de 64 MB de RAM adi-
cionais (recomendados 128 MB adicionais).
Disco Rígido* Os requisitos de espaço no disco rígido dependem da quanti-
dade de serviços instalados no computador:
50 MB de espaço disponível no disco rígido, necessário
para a instalação típica do Microsoft Project Server.
Os clientes que instalarem o SharePoint Team Services
terão de dispor de 70 MB adicionais para uma instalação
típica, mais 5 MB para cada Web site provisionado.
Os clientes que instalarem o SQL Server 2000 terão de
dispor de 250 MB adicionais para a instalação típica do
SQL Server.
Os clientes que instalarem o SQL Server Analysis Servi-
ces terão de dispor de 130 MB adicionais para a instalação
típica do Analysis Services.
A instalação de serviços adicionais requererá mais espaço
no disco rígido.
Drive Drive CD-ROM
256 cores.
Mouse Microsoft Mouse, Microsoft IntelliMouse® ou dispositivo apon-
tador compatível.
*O tipo de processador, a memória RAM e os requisitos do disco rígido dependem diretamente da quan-
tidade de serviços instalados no computador. Os requisitos mínimos presumem que apenas os componen-
tes do Microsoft Project Server sejam instalados (isso significa que o SharePoint Team Services, o SQL
Server e outros serviços serão executados em outros computadores).

Programas Relacionamos a seguir os programas necessários para armaze-

namento de dados e gerenciamento:
Para o armazenamento de dados no servidor é necessário
o Microsoft SQL Server 2000 ou superior ou o Microsoft
Desktop Engine (MSDE) já incluído. Para projetos cor-
porativos e gerenciamento de recursos é necessário o
SQL Server 2000 ou superior.
Microsoft Internet Information Services (IIS) versão 5.0
ou superior.
Microsoft Project Web Access

A configuração de sistema recomendada para o Microsoft Project Web Access é um
computador com processador de 300 MHz (megahertz) e 192 MB (megabytes) de
RAM, rodando sob o sistema operacional Microsoft Windows® XP Professional.
Obs.: O Microsoft Project Web Access é a interface Web do Microsoft Project
Server. O uso do Microsoft Project Web Access requer a instalação de uma licença
de cliente CAL (Client Access Licence) do Microsoft Project Server.
Requisitos mínimos
Computador/ PC com processador Pentium de 133-megahertz (MHz) ou
Processador superior.
Sistema Windows 98, Windows 98 Second Edition, Windows Millen-
Operacional nium Edition (Windows Me), Microsoft Windows NT® ver-
são 4.0 com o Service Pack 6 (SP6) ou posterior, Windows
2000 Professional ou Windows XP Professional.
Memória Os requisitos de RAM dependem do sistema operacional em
uso:
crosoft Project Web Access.
Microsoft Project Web Access.

CAPÍTULO 11 275

ração e da quantidade de serviços instalados no computador:
Necessários de 5 MB a 15 MB de espaço disponível no
disco rígido para a instalação típica do Microsoft Project
Web Access.
A instalação de serviços adicionais demanda mais espaço
no disco rígido.
256 cores.
Mouse Microsoft Mouse, Microsoft IntelliMouse® ou dispositivo apon-
tador compatível.
Programas Microsoft Internet Explorer 5.01 ou superior (Recomendado
Internet Explorer 5.5 ou superior).
Benefícios de migração
Este tópico é apresentado para as organizações que já possuem as soluções da Micro-
soft para os seus ambientes de gerenciamento de projetos e estão avaliando a possibi-
lidade de migração.
Através de ferramentas mais intuitivas, o Microsoft Project Standard permite que
você dê início imediato a um projeto, mantendo o total controle durante todo seu
andamento, com informações detalhadas de seu cronograma, custos e recursos.
As novas ferramentas aperfeiçoadas de gerenciamento de projetos incluem:
Planejamento intuitivo. Com o Guia de Projetos, você dá início imedia-

to ao seu projeto. Sua guia de instruções orienta o usuário, passo a passo, a or-
ganizar um projeto, gerenciar as tarefas e os recursos, acompanhar o projeto
e reportar as informações pertinentes.
Integração total. O Project Standard 2002 oferece uma integração mais
tranqüila e transparente com outros programas da Microsoft. É possível, por
exemplo, importar listas de tarefas criadas no Microsoft Excel ou no Micro-
soft Outlook® diretamente para o Microsoft Project.
Interface com o Office. A interface mais familiar e intuitiva do Office XP
– com menus pull-down, painel informativo de tarefas e barras de comandos
– facilita ainda mais o uso do Microsoft Project, mesmo para profissionais
que nunca tenham usado o produto antes.
Facilidade de uso. Com o auxílio de novos assistentes, você poderá sim-
plificar o processo de configurar e acompanhar cronogramas de projetos.
Além disso, o Office empresta algumas de suas funcionalidades ao Microsoft
Project, tais como atalhos via teclado, caixas de texto, ajuste de colunas etc.

Ajuda num piscar de olhos. Recursos aperfeiçoados de ajuda vêm em seu

auxílio no decorrer do trabalho, sempre que necessário. Novas marcas inteli-
gentes – como as que avisam que um recurso realocado ou outra mudança está
afetando o projeto – são algumas das ferramentas de ajuda de grande utilidade.
Atualização permanente do status de um projeto. Novos assistentes
podem agora ser usados para selecionar ou personalizar sua forma preferida de
acompanhar um projeto. A partir da data de status fixada, o Project 2002 traz
opções para que você ajuste o modo como quer controlar seus projetos: pelos
resultados reais, pelo trabalho remanescente, pelos gastos já efetuados etc.
Múltiplos parâmetros de referência. Com o novo Project 2002, você
poderá acompanhar a evolução de seus projetos, monitorar as diferenças en-
tre os resultados previstos e os reais e manter todos os registros do histórico
do projeto. Você poderá salvar e armazenar mais de dez parâmetros durante
o projeto.
Alocação simplificada de recursos. Agora ficou mais fácil selecionar e
alocar os melhores recursos disponíveis para seus projetos. Basta usar as no-
vas funcionalidades de busca, filtros de seleção e novos gráficos para identifi-
car e alocar os recursos mais adequados para seus projetos.
Melhor apresentação das informações. Tenha uma visão mais abran-
gente de seus projetos, com os displays de agrupamento e apresentação das
informações disponíveis nas exibições do Diagrama da Rede e de utilização.
Exiba o Gráfico de Gantt em três escalas de tempo e uso, imprimindo apenas
os totais das colunas nos relatórios.
Maiores recursos de personalização. Agora a personalização do Mi-
crosoft Project ficou ainda mais flexível, graças ao formato de arquivos ba-
seado na linguagem XML (Extensible Markup Language), a um modelo de
objetos estendido, a um maior suporte a add-ins do modelo COM e a um me-
lhor provedor de banco de dados OLE.
Benefícios do Microsoft Project Server

Juntos, o Microsoft Project Professional e o Microsoft Project Server oferecem uma
solução abrangente de gerenciamento corporativo de projetos. Ferramentas de cola-
boração e dados compartilhados permitem que grupos de trabalho e seus integrantes
se mantenham informados, garantindo que suas iniciativas estejam alinhadas aos ob-
jetivos da organização.
O ambiente e as ferramentas personalizáveis podem ser integrados a outros siste-
mas para que projetos de empresas com as mais diferentes plataformas possam ir ao
encontro das diversas necessidades dos projetos e gerenciamento das informações
corporativas.

CAPÍTULO 11 277
Veja os principais benefícios:
Padronização corporativa. As novas ferramentas de gerenciamento de proje-

tos corporativos podem padronizar e personalizar o Microsoft Project para que se-
jam gerados e distribuídos relatórios e análises consistentes para toda a empresa.
Gerenciamento dos recursos corporativos. Com o Microsoft Pro-
ject, você obtém informações precisas sobre a disponibilidade de recursos da
empresa, o que assegura sempre a alocação da melhor equipe para cada pro-
jeto. Gerencie os recursos visualmente, por meio de gráficos de disponibili-
dade e de utilização, ou deixe que o Assistente de Substituição de Recursos
analise as aptidões necessárias para determinado projeto, destacando os pro-
fissionais mais adequados para concretizá-lo.
Análise de simulações. Com a ajuda de ferramentas de simulação e de
análise, que avaliam a alocação de recursos, dos cenários e dos dados gerais
de um projeto, você adquire visibilidade total sobre as operações de sua em-
presa para tomar decisões mais abalizadas.
Colaboração entre as equipes. Através da ferramenta Microsoft Project
Web Access, as equipes e demais participantes autorizados de um projeto
podem colaborar entre si, visualizando ou atualizando o projeto, ou fazendo
consultas para obter mais informações que contribuam para o projeto – tudo
isso com o simples uso de um browser de Internet.
Centralização. Agora ficou mais fácil organizar, acompanhar e armazenar
detalhes relativos a um projeto a partir de um único ponto central. O Share-
PointTM Team Services é um serviço de integração Web que permite que do-
cumentos sejam conectados a tarefas ou a projetos; ele possibilita ainda o
compartilhamento de documentos e o acompanhamento de problemas em
projetos individuais depositados no servidor do Microsoft Project Server.
Planejamento intuitivo. Com o uso do Guia de Projetos, aumenta-se a
produtividade. O Guia de Projetos é uma nova ferramenta intuitiva que aju-
da na montagem do planejamento, no acompanhamento do projeto e no
acesso direto a muito mais recursos do Microsoft Project. As novas marcas
inteligentes detectam quando realocações de recursos ou outras alterações
estão afetando o cronograma do projeto e apresentam algumas alternativas.
Maior integração. Agora existe uma integração muito próxima, além de
uma transição quase imperceptível, entre o Microsoft Project e outros apli-
cativos da Microsoft. Listas de tarefas criadas no Microsoft Excel, Microsoft
Outlook ou no Microsoft Project Web Access podem ser importadas direta-
mente para o Microsoft Project. Além disso, a interface e a barra de ferra-
mentas do Microsoft Office simplificam o uso do Microsoft Project em rela-
ção às versões anteriores.

Maior escalabilidade. Os recursos de equilíbrio de carga (load-ba-

lancing), arquitetura em múltiplas camadas e funcionalidades OLAP (pro-
cessamento analítico on-line) – todos eles baseados na tecnologia do Micro-
soft SQL ServerTM – permitem que o Microsoft Project Server controle as
crescentes necessidades de processamento de sua empresa.
Maior possibilidade de personalização. A partir dos próprios aplica-
tivos em uso, o gerente de projetos poderá desenvolver Guias de Projetos
personalizados que se baseiem em casos bem-sucedidos dentro da empresa.
A personalização dos aplicativos do Microsoft Project ficou mais flexível gra-
ças ao novo formato de arquivos baseado na linguagem XML (Extensible
Markup Language), a um modelo de objetos ampliado, ao suporte a add-ins
no padrão COM e ao novo provedor de banco de dados OLE.
Arquitetura aberta. Integre o Microsoft Project a outras aplicações e
bancos de dados aproveitando seu suporte total aos padrões de mercado, tais
como o sistema de mensagens XML e SOAP.
Quadro comparativo entre as versões do Microsoft Project

O Microsoft Project 2002 é disponiblizado pela Microsoft em duas edições: Enter-
prise Project Management e Microsoft Project Standard 2002.
A seguir está uma tabela comparativa entre as duas versões.
Microsoft Enterprise
Project Project
Recursos Standard Manage-
2002 ment
Ferramentas de planejamento intuitivas
Agendamento dinâmico de tarefas l l
Gráficos de Gantt, calendário e planilhas de tarefas l l
Guia de Projetos, uma intuitiva ferramenta de Ajuda 3 3

Interface com o Microsoft Office XP 3 3
Marcas inteligentes 3 3
Integração com o Microsoft Excel e o Microsoft Outlook® l l
Gerenciamento de Recursos
Nivelamento de recursos l l
Gráficos de disponibilidade de recursos 3 3

CAPÍTULO 11 279
Microsoft Enterprise
Project Project
Recursos Standard Manage-
2002 ment
Central de recursos corporativos 3
Alocação e substituição de recursos com base nas aptidões 3
individuais
Ferramentas de colaboração
Notificações por e-mail l
Planilhas de prazos e relatórios de status* l
Biblioteca de documentos* 3
Identificação de problemas* 3
Ferramentas de análise e de reporting baseadas na Web
Exibições do conjunto de projetos* l
Ferramentas de modelagem e de análise de cenários* 3

Relatórios em tempo real* 3
Plataforma Expansível
Formato de arquivos em XML 3 3
Códigos corporativos e campos personalizados 3
Modelos corporativos 3
Camada de segurança para proteção dos dados do projeto 3
Recursos de equilíbrio de carga (load-balancing) e de clustering 3
Para a total funcionalidade no gerenciamento de projetos corporativos, o Microsoft Project Ser-

ver 2002 requer a instalação do Microsoft Windows® 2000 Server e do Microsoft SQL ServerTM
2000. O uso dos recursos e serviços do Microsoft Project Server, incluindo o Microsoft Project
Web Access – a interface Web do Microsoft Project Server – requer a instalação de uma licença
de cliente CAL (Client Access Licence) do Microsoft Project Server.
* Recursos disponíveis através do Microsoft Project Web Access.
Legenda:
l = Recurso incluído
l = Melhorado no Microsoft Project 2002
3 = Novo no Microsoft Project 2002

Nova Versão do Microsoft Project 2007

O CD que acompanha este livro disponibiliza o aplicativo Microsoft Project 2007
Beta para instalação. Confira na pasta \MSPROJECT2007BETA\. Para a devida uti-
lização do aplicativo, você precisa visitar o link http://www.microsoft.com/office/pre-
view/beta/getthebeta.mspx. Chegando lá, clique no botão “Download The Beta Now”,
selecione o país “Brasil”, clique no botão “Go”. Se você não tiver uma “ID Windows
Live”, crie uma para continuar. Se você já tiver uma “ID Windows Live” informe o
e-mail e a senha e clique em “Enter”. Você será redirecionado para uma outra página.
Nesta, informe novamente o seu e-mail e o idioma “English”. Siga as próximas ins-
truções. Você receberá o link e a chave de instalação por e-mail.
Para ter uma visão de toda suíte de aplicativos Microsoft Office versão 2007 aces-
se o link: http://www.microsoft.com/office/preview/default.mspx
A Microsoft descreve os dez motivos principais para fazer o upgrade do Microsoft
Project no seguinte link: http://www.microsoft.com/office/preview/programs/
project/top10.mspx
Maiores informações sobre a nova versão do Microsoft Project 2007 podem ser
acessadas no link: http://www.microsoft.com/office/preview/programs/pro-
ject/highlights.mspx
Veja abaixo todos aplicativos da versão 2007 que a Microsoft está disponibilizando
para download:
Tamanho Taxa de Download em KBPS
Programas em MB 56 128 256 1028
Microsoft® Office Professional Plus 2007 550 164 72 36 9
Microsoft® Office SharePoint® Designer 2007 305 91 40 205
Microsoft® Office Visio® Professional 2007 330 98 43 21 5
Microsoft® Office OneNote® 2007 279 83 36 18 5
Microsoft® Office Project Professional 2007 285 85 37 19 5
Microsoft® Office Groove® 2007 300 89 39 20 5
All Programs and Suites 2.049 610 267 133 33
Servers
Microsoft® Office SharePoint® Server 2007 1.000 298 130 65 16
Microsoft® Office Project Server 2007 300 89 39 20 5
Microsoft® Office Groove® Server 2007 300 89 39 20 5
Microsoft® Office Forms Server 2007 110 33 14 7 2
All Servers 1.710 509 222 111 28
Additional Services
Microsoft® Office Outlook® 2007 with Business 380 113 49 25 6
Contact Manager
Microsoft® Office Language Pack 2007 – German 290 86 38 19 5

CAPÍTULO 11 281
PRIMAVERA TEAM PLAY

Fabricante: Primavera
Web Site: www.primavera.com
Visão geral
O Primavera TeamPlay é um produto concebido para gerenciar projetos de tec-
nologia da informação e de desenvolvimento de software.
A suíte é composta de Collaboration, Portifolio Management, Resourse Management,
Process Management e Work Order Management.
Collaboration permite o gerenciamento corporativo de projetos.
Portifolio Management analisa portifolios de projetos em seus contextos próprios.
Resouce Management gerencia os recursos do projeto.
Process Management gerencia metodologias.
Work Order Management permite a automatização de atividades.
Informações sobre o produto Primavera TeamPlay

Esta seção está dividia em:
Arquitetura funcional do produto
Recursos e especificações
Suíte de componentes
Produtos que acompanham o Primavera TeamPlay
Produtos que se integram com o Primavera TeamPlay
A arquitetura funcional do produto

A arquitetura funcional do Primavera TeamPlay é dividida da seguinte forma: Re-
source Manager, Executive, Remote Project Manager, Portfolio Manager/Profes-
sional Project Manager, Team Lead/Novice Project Manager e Project Participant.
A Figura 11.25 ilustra a arquitetura funcional do produto.
Nos próximos itens veremos alguns exemplos dessa arquitetura funcional.
Recursos e especificações
1. Utilizando um browser, os membros da equipe do projeto informam o tem-
po gasto e o tempo que ainda resta para completar as tarefas, alertando os
gerentes de projetos sobre os status das atividades.
2. Gerentes de projetos podem rapidamente iniciar novos projetos utilizando
melhores práticas estabelecidas (CMM, PMI, entre outras), entregas (deli-
verables) definidas e prazos predeterminados. O painel do projeto notifica o
gerente do projeto sobre as atividades críticas, atividades pendentes men-
sais, semanais e diárias (Figura 11.27).

F I G U R A 1 1 . 2 5 Arquitetura do primavera TeamPlay
F I G U R A 1 1 . 2 6 Apontamento de horas no TeamPlay
3. Gerentes de recursos e funcionais podem alocar e atualizar os recursos sem

que eles sejam os gerentes de projeto. Eles têm as informações de que ne-
cessitam para assegurar a contratação de pessoal qualificado nos projetos
certos. O Primavera TeamPlay ajuda os gerentes a identificar recursos supe-
ralocados ou recursos pouco alocados, e a determinar se a alocação dos re-
cursos vai de encontro com os objetivos estratégicos e estimativas futuras de
alocação (Figura 11.28).

CAPÍTULO 11 283
F I G U R A 1 1 . 2 7 Melhores práticas
4. Executivos e envolvidos no projeto são informados sobre a saúde dos proje-

tos utilizando os Executive Dashboards do Primavera TeamPlay. Os envolvi-
dos no projeto podem selecionar e balancear portfolios e projetos. Uma vi-
são customizada do portal de projetos de missão crítica possibilita rapida-
mente monitorar a performance, as estatísticas e a situação do projeto, ob-
tendo informações em diversos níveis de detalhes para tirar suas devidas
conclusões (Figura 11.29).
5. O Primavera TeamPlay dispõe de ferramentas avançadas de cronogarama,
modelagem e nivelamento de recursos e análise de caminho crítico.
Suíte de componentes
Produtos que acompanham o produto Primavera TeamPlay:
gantthead.com
Um conjunto de serviços e uma biblioteca que auxilia os gerentes de projeto.
Entre os serviços estão:
Consultoria remota
Implementação de gerenciamento de processos

F I G U R A 1 1 . 2 8 Gráfico de alocação de recursos
F I G U R A 1 1 . 2 9 Performance do portifólio de projetos

CAPÍTULO 11 285
F I G U R A 1 1 . 3 0 Ferramentas Avançadas
Conteúdo customizado on-line

Aconselhamento exclusivo de um especialista
Modelos e planos de projetos para downloads
E a biblioteca é composta por:
Processos de solução de aplicação

Processo de Data Warehouse
Processo de desenvolvimento de aplicações distribuídas
Processo de gerenciamento de projetos “PACE”
Processos de implementação “Siebel”
Processos de avaliação “Value Stream”
Processos de desenvolvimento “WebWAVE”
Processos de desenvolvimento “WebWAVE Ongoing”
Contatos GanttHead
3050 Chain Bridge Road Suite 600
Fairfax, VA 22030-2834
World Wide Web: www.gantthead.com
Email: customerservice@gantthead.com
Telephone: +1.877.895.6506

Produtos complementares de parceiros Primavera Team Play

A Primavera conta com uma série de parceiros para solucionar necessidades específi-
cas de negócios. Abaixo cito estes parceiros, bem como suas soluções de integração
com o produtos Primavera.
BEA Systems – BEA WebLogic – Servidor de aplicação compatível com produ-

tos Primavera.
Critical Tools – (WBS Chart Pro, PERT Chart EXPERT) – Critical Tools ofe-
rece ferramentas flexíveis para construção de WBS e PERT que podem ser uti-
lizadas com produtos Primavera.
Cost Xpert Group, Inc. – (SEER-SEM) Ferramenta utilizada para produzir estimati-
vas de custos, cronogramas e esforços para projetos de desenvolvimento de software.
Galorath Incorporated – (SEER-SEM) Uma ferramenta utilizada para produzir
estimativas de custo, cronograma e esforço para projetos de desenvolvimento
de software.
gantthead.com – Biblioteca de processos gantthead integrado com o TeamPlay.
High Profile IT – (documentação de projetos, publicação e gerenciamento).
HMS Software (Sistema de Gerenciamento Heurístico) – (apontamento, rela-
tórios de despesas, “TimeControl”).
Impac – (Project Data Interface (PDI)) – Oferece software e serviços para inte-
gração das ferramentas de agendamento Primavera e aplicações Oracle.
IMPRESS Software Inc. – Este parceiro é especializado em fornecer integração
de software e serviços entre os sistemas SAP e Primavera.
Innovative Management Solutions, Inc. – IMS oferece um utilitário de atualiza-
ções de linhas bases – uma ferramenta para manter as linhas bases de projetos
com as últimas aprovações.
InSynchro (Collaboration, “Project Hub”) – Project Hub permite que empre-
sas de engenharia acessem informações no Primavera através da Internet.
LinkEdge Technologies – LinkEdge oferece um sistema de gerenciamento de ques-
tões chamado PointinSight que pode ser utilizado com o software Primavera.
Miko Technologies – Gráficos avançados para produtos Primavera.
Mindjet – (MindManager) – Oferece mapeamento visual que pode ser utiliza-
do com os produtos Primavera.
Project Partners – Oferece interfaces pré-configuradas entre produtos Prima-
veras e aplicações Oracle.
Risk Decisions Ltd – (Risk Analysis) – Ferramenta de análise de riscos e interfa-
ce com os produtos Primavera.
Symbol Technologies – Soluções portáteis (handheld) para serem utilizadas
com o Primavera Mobile Manager.
Telelogic – Integração entre o Telelogic DOORS – sistema de gerenciamento
de requisitos – o P3e e o TeamPlay.

CAPÍTULO 11 287
Para finalizar, a título de informação, a organização Primavera possui uma linha de

produtos de gerenciamento de projetos, a saber:
Primavera Enterprise
Primavera Expedition
PrimeContract
Primavera Project Planner
Primavera SureTrack Project Manager
Mais informações, acesse o Web site da Primavera.
PMOFFICE
Fabricante: SystemCorp
Web Site: www.systemcorp.com
O PMOffice é uma solução para automatizar o gerenciamento corporativo de port-
folios de projetos, recursos e prioridades ao longo de toda a organização. A partir de
um ponto centralizado, é possível controlar entregas (deliverables), orçamento, tare-
fas, mudanças e riscos.
Sobre o PMOffice serão abordados brevemente os seguintes tópicos:
PMOffice Enterprise Architecture

Time Tracking
Project Accounting
Change, Issue e Risk Management
Project Document Management
Project Collaboration
Reusable Methods
Inter-project Dependencies
Integration With Schedulers
Capacity and Resource Planning
Portfolio Dashboard
PMOffice Enterprise Architecture

A Arquitetura do PMOffice suporta diversos padrões de tecnologia da Internet, tais
como HTTP, XML, Web Server (Java Servlets), WAP (Wireless Application Proto-
col) e Enterprise Application Integration (EAI).
É compatível com os principais sistemas operacionais de baixa e alta plataformas
(Windows NT/2000 e Unix), bancos de dados (IBM DB2, Oracle, MS-SQL) e aces-
so a dados via ODBC e JDBC (Figura 11.31).

ARQUITETURA CORPORATIVA DO PMOFFICE

Apresentação
Customizações do
usuário
Comunicação
Repositório
Permite Internet Banco de dados
Intranet
Workflow
Permite Wireless Sistemas
Relatórios Legados
Segurança
APIs XML
F I G U R A 1 1 . 3 1 Arquitetura Enterprise PMOffice
Time Tracking
O módulo de gerenciamento de tempo do PMOffice é simples, inovativo e contém
em um único ponto uma interface de entrada de apontamentos das horas do projeto.
Ele foi desenvolvido com um número de recursos para economizar o tempo,
combinando o monitoramento do tempo das atividades com a captura de informa-
ções previstas.
Cada tarefa pode incluir o tempo real, o estimado para completá-la e o percentual
completado. Tarefas também podem ser configuradas pela inclusão de datas de iní-
cio e fim.
A Timesheet View é facilmente configurada e intuitiva para novos usuários. Usuá-
rios podem adicionar ou remover colunas arrastando e soltando. A personalização
pode ser feita para visualizar apenas elementos específicos.
Os filtros do Timesheet também estão disponíveis para ajudar os usuários a pro-
duzirem a visão que melhor se adapta às suas necessidades imediatas. O PMOffice re-
conhece que os recursos terão diferentes níveis de responsabilidade e, como tais, se-
rão requeridos níveis adicionais de filtros.
As visões de apontamento fornecidas com o PMOffice são baseadas em uma estru-
tura de três camadas, contornadas pelas responsabilidades dos recursos e acessos de
segurança. As três categorias de filtros são definidas como: My Work, My Projects e My
Resource Pools (Figuras 11.35, 11.36 e 11.37).

CAPÍTULO 11 289
F I G U R A 1 1 . 3 2 PMOffice Visão de apontamento
F I G U R A 1 1 . 3 3 Time Details
F I G U R A 1 1 . 3 4 Configuração de coluna e banda

Fornece uma visão dos pacotes

de trabalho
Fornece uma visão das tarefas
F I G U R A 1 1 . 3 5 Exemplo de My Work
Fornece uma visão de todas as tarefas

da equipe em um projeto de usuário
Fornece uma visão de todas

as tarefas dos recursos

as tarefas de um projeto
F I G U R A 1 1 . 3 6 Exemplo de My Project
Fornece uma visão de todos os pacotes de trabalho

as responsabilidades por
projeto e por recursos
Fornece uma visão de todos
os pacotes de trabalho em
todos os projetos
Fornece uma visão de todas as tarefas
dos recursos em todos os projetos
F I G U R A 1 1 . 3 7 Exemplo de My Resource Pools

CAPÍTULO 11 291
As opções de filtros do PMOffice estão ilustradas na Figura 11.38:
Visualiza todas as responsabilidades que não estão concluídas

Visualiza as responsabilidades em aberto em andamento
Visualiza as responsabilidades em aberto para o próximo mês
Visualiza as responsabilidades em aberto para a próxima semana
Visualiza todas as responsabilidades concluídas
Visualiza todas as responsabilidades independentes dos seus status
F I G U R A 1 1 . 3 8 Opções de filtro do PMOffice
Os recursos também podem “quebrar” as tarefas em atividades menores, confor-

me ilustrado:
F I G U R A 1 1 . 3 9 TimeSheet View com quebra de tarefas

O TimeSheet View também pode ser configurado para capturar métricas de valo-
res agregados (BCWS, CV, BAC, ACWP, EAC, VAC, BCWS, SV,CPI, SPI e Criti-
cal Ratio).
F I G U R A 1 1 . 4 0 TimeSheet View com informações de Valores Agregados (EVA)
Para facilitar a captura e o acompanhamento de despesas incorridas e realizadas, o

PMOffice permite aos participantes do projeto entrar com informações de despesas
e utilizá-las em seus respectivos códigos de contas contábeis (Figura 11.41).
O PMOffice também suporta outros tipos de práticas de reportar despesas por fa-
turamento e códigos de contas contábeis; múltiplas despesas e múltiplas conversões
de moedas. Para isso, é preciso arrastar e soltar o ícone de faturamento na tarefa e en-
trar com as informações apropriadas (Figuras 11.42 e 11.43).
Arrastando um ou múltiplos ícones de despesas num novo faturamento, o usuá-
rio poderá entrar com as informações relacionadas, utilizando somente aquelas
contas contábeis que estão associadas ao projeto. Variações de custos são calcu-
ladas em tempo real, reduzindo o potencial de riscos e utilização de contingência
(Figura 11.44).

CAPÍTULO 11 293
F I G U R A 1 1 . 4 1 TimeSheet View
F I G U R A 1 1 . 4 2 TimeSheet View – Ícones
Project Accounting
Este recurso permite realizar estimativas de custos do tipo “top-down” e o orçamen-
to de atividades do tipo “bottom-up” e capturar despesas em tempo real através do
ciclo de vida do projeto.
Utilizando esses recursos, os participantes do projeto são capazes de gerenciar as
despesas do projeto e proativamente planejar, estimar e acompanhar os custos incor-
ridos.

F I G U R A 1 1 . 4 3 TimeSheet View – Detalhes de faturamento
F I G U R A 1 1 . 4 4 TimeSheet View – Contas contábeis

CAPÍTULO 11 295
F I G U R A 1 1 . 4 5 Estimativa de custo de cima para baixo
Change, Issue e Risk Management

O PMOffice fornece às organizações mecanismos padronizados e automatizados
para gerenciar, acompanhar (monitorar) as diferentes mudanças e solicitações de
mudanças resultantes do projeto. Todas as mudanças são centralizadas num reposi-
tório, priorizado e classificado (Figura 11.46).
Project Document Management

O PMOffice fornece todas as funções para controle e gerenciamento do ciclo de vida
dos documentos do projeto, incluindo criação de documentos, recisões, distribui-
ção e aprovação através de sistemas colaborativos de workflow. Os documentos são
gerenciados através de funções de Check-in/Check-out e de sistemas de controle de
revisão (Figura 11.47).
O PMOffice permite que todos os membros do time do projeto anexem docu-
mentos a suas tarefas individuais e também consultem toda documentação que foi
anexada para suas designações pelo gerente de projeto.
Em qualquer nível da WBS, gerentes de projetos e membros do time do projeto
podem criar pastas para armazenar vários tipos de documentos. Uma estrutura hie-
rárquica de pastas e documentos pode ser criada, permitindo uma associação lógica e
intuitiva de documentos, facilitando o acesso à informação. Todos os documentos

F I G U R A 1 1 . 4 6 Exemplo de gerenciamento de riscos
F I G U R A 1 1 . 4 7 Visão de Documentos

CAPÍTULO 11 297
F I G U R A 1 1 . 4 8 PMOffice Check in de documentos
anexados em quaisquer níveis da WBS são agregados aos elementos do projeto e po-
dem ser vistos instantaneamente.
Durante as várias fases do projeto, os gerentes de projeto podem distribuir docu-
mentos para os sponsors (donos ou patrocinadores) do projeto e para todos os envol-
vidos, de modo que sejam revisados e aprovados.
Os seguintes recursos são aplicados a quaisquer documentos associados à WBS:
Recurso de check-out para assegurar as modificaçõeos simultâneas de docu-

mentos.
Recurso de check-in com versionamento automático.
Prefixos de documentos e número de campos definidos pelo usuário.
Atributos de documentos que são definidos pela organização do projeto e são
utilizados para categorizar documentos.
Os documentos são editados na aplicação original utilizada para criá-los.

Project Collaboration
O PMOffice gerencia, automatiza e monitora o fluxo do trabalho do projeto. Os
processos do projeto são configurados e automatizados para serem utilizados através
do ciclo de vida do projeto.
O ambiente de workflow do PMOffice é intuitivo e permite acesso a informações

históricas de todos os passos realizados nos processos. Todas as solicitações e resulta-
dos relacionados são gravados e armazenados em um repositório “contra” os elemen-
tos originais do projeto. Isso garante a completa monitoração dos processos, permi-
tindo revisão de processos e auditoria (Figura 11.49).
Para fornecer informações dos eventos aos gerentes e participantes do projeto, o
PMOffice possui recursos de alertas e gatilhos. Isso garante que assim que um evento
específico ocorrer no projeto, uma notificação via e-mail é “disparada” para as pes-
soas responsáveis.
Alguns dos eventos configuráveis incluem: mudança de custo, variações no cro-
nograma, novas dependências de tarefas no projeto, interdependência entre proje-
tos, alterações na qualidade, variações no escopo, finalização de tarefas, entre ou-
tros. Quando um gatilho é disparado ou quando um treshold é alcançado, os responsá-
veis são imediatamente notificados via e-mail.

CAPÍTULO 11 299
F I G U R A 1 1 . 4 9 Módulo de workflow do PMOffice
Reusable Methods
No PMOffice™, para facilitar o trabalho, você pode capturar e reutilizar planos de
projetos e modelos de trabalho. Gerentes autorizados podem publicar vários méto-
dos, arrastando e soltando para a área dos templates (Figura 11.50).
Templates podem incluir estimativas de esforços, todos os documentos necessá-
rios para ajudar os participantes a criar planos mais consistentes e de alta qualidade,
evitando ter de “reinventar a roda”. Isso economiza tempo e dinheiro, criando um in-
ventário de valiosos “bens” para reutilização.
Inter-project Dependencies
O PMOffice fornece aos gerentes de projetos e aos membros do time a habilidade de
criar interdependência entre tarefas em diferentes projetos dentro da organização.
Se, por exemplo, um participante do projeto inserir uma dependência predecessora
e a data daquela predecessora for alterada, o PMOffice enviará um e-mail notifican-
do a mudança para o gerente de projetos. Gerentes de projetos também podem con-
solidar e nivelar seus cronogramas para utilização em múltiplos projetos.
É muito comum o compartilhamento de recursos entre os projetos nas organiza-
ções. Geralmente um problema numa tarefa de um projeto afeta os outros que são

F I G U R A 1 1 . 5 0 Visão de modelos
F I G U R A 1 1 . 5 1 PMOffice Gantt View entre múltiplos projetos

CAPÍTULO 11 301
dependentes. O PMOffice permite aos gerentes de projetos criar tarefas dependen-

tes entre múltiplos projetos. Uma vez estabelecidas as dependências, os gerentes po-
dem exportar as tarefas de volta para serem consolidadas no “Master Project”. Após
consolidação e renivelamento dos dados, o PMOffice permite aos gerentes publicar
novamente os dados de volta em seus projetos individuais.
Integration With Schedulers

O PMOffice se integra com o Microsoft® Project 2000 e 2002.
Capacity and Resource Planning

O efetivo gerenciamento de recursos começa com a compreensão da utilização dos
recursos da organização e com um invetário de habilidades. Através da consodilação
de múltiplos projetos num repositório central, as organizações podem ganhar visibi-
lidade necessária para planejar e balancear sua carga de tabalho. O PMOffice man-
tém um modelo completo da capacidade de uma organização, recursos afetados, in-
ventário de habilidades, carga total de trabalho e demanda de recursos. Essa capaci-
dade e o módulo de planejamento de recursos permitem que as organizações otimi-
zem o uso das habilidades e asseguram que todos os recursos de missão crítica estão
produtivamente alinhados com as altas prioridades dos projetos.
O PMOffice transforma os processos de centralização, manutenção e distribuição
de informação pessoal capacitando cada membro do time a auto-administrar suas ati-
vidades.
É possível integrar os calendários pessoais em um banco de dados central de recur-
sos e capacitar individualmente os membros do time para manter conhecimentos,
habilidades e experiências que eles adquiriram nos projetos.
Os membros dos times do projeto têm completo acesso a competências, informa-
ções de habilidades, histórico empregatício e outros dados pertinentes que devem
ser mantidos para fornecer aos gerentes informações sobre os recursos e, dessa for-
ma, balancear adequadamente a carga de trabalho. O PMOffice também permite
que os recursos sugiram habilidades necessárias alinhadas com os seus objetivos de
carreira. Essas informações podem ser utilizadas para assegurar que as decisões da
equipe do projeto estejam vinculadas ao crescimento pessoal do funcionário. Após
cada alteração nos registros, o sistema pode ser configurado para gerar alertas e soli-
citar revisões gerenciais e aprovações.
Os gerentes podem planejar iniciativas que consideram todas as restrições e prio-
ridades do portfolio de projetos da organização. Começando com uma WBS intuiti-
va, os gerentes podem arrastar e soltar elementos, tais como projetos, entregas (deli-
verables), tarefas, milestones, e planejar iniciativas que refletem as capacidades reais
dos recursos (Figura 11.55).
A Pool View exibe a forma de trabalho a partir de uma perspectiva funcional. A gerên-
cia pode visualizar as prioridades da organização para cada projeto (Figura 11.56).

F I G U R A 1 1 . 5 2 Registro pessoal
F I G U R A 1 1 . 5 3 Calendário pessoal

CAPÍTULO 11 303
F I G U R A 1 1 . 5 4 Visão de habilidade do recurso
F I G U R A 1 1 . 5 5 Visão Staffing

F I G U R A 1 1 . 5 6 Pool Administration
Portfolio Dashboard
O Enterprise Project-portfolio Management (PPM) lida com o alinhamento das pes-
soas, os projetos e as prioridades da organização. Através do controle de gastos do
capital e de recursos das pessoas e indentificando em quais projetos investir, o PPM é
um método que demonstra como você operacionaliza sua estratégia de negócio.
Informações de scorecard são exibidas de forma visual.
Através de gráficos e pivot tables, as pessoas que decidem podem visualizar e alcan-
çar o esperado balanceamento dos projetos e pessoas, alinhando os portfolios com as
estratégias do negócio. Os participantes podem também realizar detalhados ROI,
pay-back e análises de break-even utilizando AIE, NPV, IRR e diversos modelos financei-
ros para determinar quais oportunidades são mais lucrativas (Figura 11.58).
O Portfolio Dashboard é um recurso interessante. Os usuários começam revendo
seus portfolios a partir de várias perspectivas: mapas, scorecards, cubos multidimen-
sionais, entre outros.
O Portfolio Quick-Dash é uma ferramenta inovativa que economiza tempo de
operação no Portfolio DashBoards. Com um simples clique de mouse em qualquer
elemento são fornecidas informações resumidas de todas as áreas críticas do projeto.
Algumas medidas exibidas são cronogramas, orçamentos, lucros, aspectos críticos,

CAPÍTULO 11 305
F I G U R A 1 1 . 5 7 PMOffice Portfolio Scorecard
F I G U R A 1 1 . 5 8 PMOffice Portfolio Dashboard

riscos, margens e ROI. O Quick Dash também fornece brevemente todos os parâ-
metros do portfolio configurados pelos usuários (Figura 11.59).
O PMOffice Portfolio Dashboard estende os recursos de medidas do PMOffice.
Os gerentes podem configurar as medidas disponíveis, thresholds e gatilhos mais in-
tuitivamente, através da janela de configuração.
Para auxiliar os gerentes e executivos nas análises financeiras, uma série de cu-
bos multidimensionais foram adicionados. O Portfolio Dashboard também con-
densa múltiplos relatórios em uma pequena coleção de macros envolvendo as
áreas do projeto. Um tipo de macro, “project detail”, incorpora vários relatórios
clássicos do tipo profile do projeto, status do projeto, orçamento do projeto, mi-
lestones e do projeto, dependências do projeto, mudanças, riscos, documentos e
métricas de valor agregado (EVA) em uma única macro. Ao todo, são incluídas
18 macros. Uma completa ferramenta de customização de relatórios também é
disponibilizada (Figura 11.60).
OPEN PROJECT SYSTEM (SAP)

Fabricante: Sap
Web site: http://service.sap.com/ps
O Open Project System, também conhecido como SAP R/3 PS, baseado na tec-
nologia EPS 4.0 (BAPI), é uma suíte das novas aplicações de negócios SAP para aces-
sar o R/3 de sistemas externos.
As versões atualmente disponíveis são para Microsoft Project e para sistemas por-
táteis do tipo Palm.
O download dessa suíte pode ser feito sem custos extras no Web site citado. Exclu-
sivo para usuários da SAPNet, para acessar o Web site e fazer o download do Open
Project System, são solicitados um login e uma senha, conforme a Figura 11.61.
Serão abordadas brevemente as duas versões do SAP R/3 PS.
Open Project System Para Microsoft Project

Objetivos
Trabalhar em um projeto sem conexão permanente com sistemas R/3 (Off-line).
Criar novos projetos R/3 com o Microsoft Project.
Apresentar projetos R/3 com o Microsoft Project.
Intercambiar projetos usando formatos de arquivos do Microsoft Project.
Utilizá-lo com “Engenharia Colaborativa” & Gerenciamento de Projetos.
Mas NÃO…
Utilizar o Microsoft Project como uma nova interface com o usuário.

Implementar todas as funcionalidades do R/3 OS no Microsoft Project.

CAPÍTULO 11 307
F I G U R A 1 1 . 5 9 Portfolio Quick-Dash
F I G U R A 1 1 . 6 0 Portfolio de exceções

F I G U R A 1 1 . 6 1 Requisição de Login e Senha na SAPNet
Arquitetura da tecnologia
Cenários
Criar um projeto no SAP R/3 OS baseado em um projeto no Microsoft Project
Criar um projeto no Microsoft Project baseado em um projeto do SAP R/3 PS
Atualizar mudanças no SAP R/3 OS ou no Microsoft Project
F I G U R A 1 1 . 6 2 Arquitetura da Tecnologia
Open Project System SAP
Características
Disponível na SAPNet
Suporta os releases SAP R/3: 4.5 e 4.6
Objetos Suportados:
Definições de projetos
Elementos da WBS
Redes
Atividades
Relacionamentos
Elementos de atividade (somente na release 4.6)
Milestones (somente na release 4.6)

CAPÍTULO 11 309
Open Project para Palm
Objetivos
Transferir atividades de rede do SAP R/3 OS para 3Com Palm
Realizar confirmações das atividades com o Palm
Conectar o R/3 e sincronizar para transferir dados de confirmação
Arquitetura da tecnologia
F I G U R A 1 1 . 6 3 Aquitetura da Tecnologia
SAP R/3 PS – Palm
Cenário 1
Selecione suas atividades a partir do SAP R/3 usando o OpenPS report.
Depois, sincronize-as no Palm, pressionando apenas o botão Hotsync (Fi-
gura 11.64).
F I G U R A 1 1 . 6 4 Exemplo de sincronização de atividades no Palm

Cenário 2
Clique ou escreva os dados de confirmação no Palm (Figura 11.65).
F I G U R A 1 1 . 6 5 Clicando no Palm para confirmação
Cenário 3
Sincronize as novas confirmações para o SAP R/3 PS.
F I G U R A 1 1 . 6 6 Sincronizando as confirmações no SAP R/3

CAPÍTULO 11 311
Características
Disponível desde outubro de 1999 em inglês e alemão.
Releases suportadas: 4.0 e superiores.
Dados de confirmação suportados:
Start date
Finish date
Forecast finish date
Degree of processing
Actual work
Remaining work
Final confirmation flag
RATIONAL PROJECT MANAGEMENT

Fabricante: Rational (IBM)
Web Site: www.rational.com/products/proman.jsp
As soluções Rational para gerenciamento de projetos estão divididas em três abordagens:
Processos Configuráveis
Gerenciamento dos Requisitos e Gerenciamento da Configuração de Software
Relatos (apresentações) e Métricas de Progresso
F I G U R A 1 1 . 6 7 Arquitetura Rational de Gerenciamento de Projetos

Ao longo do ciclo de vida do projeto você pode:
Monitorar e gerenciar os requisitos.

Monitorar e gerenciar as mudanças de software.
Avaliar e reportar o progresso dos projetos.
Analisar os impactos das mudanças antes de implementá-las.
Configurar os processos adequados para quaisquer tamanhos de projetos.
Processos configuráveis
O componente pertencente aos processos configuráveis é o Rational Unified Pro-
cess, ou mais conhecido pela comunidade de desenvolvedores como RUP. O RUP é
um conjunto Web de processos de engenharia de software que simplifica as ativida-
des das equipes de desenvolvimento. O RUP utiliza uma metodologia interativa de
desenvolvimento de sistemas.
O RUP unifica todo o processo de desenvolvimento e melhora a comunicação,
fornecendo a cada membro da equipe uma abordagem de desenvolvimento de soft-
ware centralizada em uma base de conhecimento on-line, que pode ser customizada
e específica para as necessidades de cada projeto.
Utilizando um browser para a navegação, cada membro da equipe pode ter acesso
instantâneo de suas estações de trabalho à base de conhecimento do RUP e aos guias
de processos.
A base de conhecimento unifica e focaliza o time através da identificação e atribui-
ções de responsabilidades, artefatos (diagramas, documentação, cases de testes e có-
digo-fonte) e tarefas para que cada membro da equipe compreenda a sua contribui-
ção para o projeto. Além disso, o RUP fornece um ambiente customizável através de
plug-ins, ferramentas mentors e extensa documentação (help) para atualização e
customização de processos de desenvolvimento.
Gerenciamento dos requisitos e gerenciamento da configuração

de software
Os componentes do gerenciamento dos requisitos e do gerenciamento da configura-
ção de software são o Rational RequisitePro e o Software Configuration Manage-
ment (Figura 11.68).
O Rational RequisitePro é uma ferramenta de gerenciamento de requisitos que
possui recursos, tais como:
Gerenciamento de requisitos no Microsoft Word

Gerenciamento de requisitos on-line ou na estação de trabalho
Gerenciamento e priorização de escopo
Análise de impacto de mudanças em tempo real

CAPÍTULO 11 313
F I G U R A 1 1 . 6 8 Arquitetura do gerenciamento da configuração de software
Integração com Rational Rose, Rational XDE, Rational ClearQuest, Rational Clear-
Case e Rational TestManager
Aplicação dos detalhes das melhores práticas de gerenciamento de requisitos
no Rational Unified Process
O componente Software Configuration Management, mais conhecido como SCM,

ajuda gerentes de projeto e suas equipes a gerenciar as mudanças ao longo do ciclo de
desenvolvimwento de software. Dentre os recursos estão:
Compartilhamento de código
Controle de versão
Processos automatizados de “tendências” de erros
Priorização de mudançãs através de processos de melhores práticas com o
UCM (Unified Change Management)
Desenvolvimento de soluções escaláveis e flexíveis
A Rational fornece o Rational ClearCase, uma ferramenta para gerenciamento de

artefatos, e o Rational ClearQuest, uma ferramenta para monitorar “defeitos” e mu-
danças, como soluções de gerenciamento de configuração de software.
Relatos (apresentações) e métricas de progresso

Os componentes de relatos (apresentações) e métricas de progresso são o Rational
ProjectConsole e o Rational TestManager Version 2002.

O Rational ProjectConsole, membro da Rational Suite Team Unifying Platform, automa-

tiza o processo de reportar ou relatar o status do projeto, criando dinamicamente um
projeto Web com as métricas de progresso baseadas na coleta de informações do am-
biente de desenvolvimento. O Rational ProjectConsole coleta ambas as métricas, padrão
e customizadas, da sua suíte de desenvolvimento Rational ou de outros produtos, apre-
sentando os resultados de forma gráfica para avaliação de progresso e qualidade. Isso
permite prever melhor quais áreas estão precisando de uma atenção especial e onde ba-
lancear os recursos para manter o cronograma dentro do prazo, além de permitir a to-
mada de decisões com base em análises quantitativas (Figura 11.69).
O Rational TestManager é uma ferramenta utilizada para todos os tipos de testes,
todas as informações relacionadas ao esforço para realizar as tarefas de testes e fun-
ciona como “testador” em cada fase do desenvolvimento do projeto. O Rational Test-
Manager pode ser utilizado para planejar, modelar (design), implementar e executar
testes e para criar relatórios.
No CD que acompanha este livro o leitor encontra pequenos vídeos (capturas de te-
las) da Rational com narrativas em inglês demonstrando graficamente, através das res-
pectivas interfaces dos produtos, a utilização de alguns dos recursos aqui apresentados.
Os arquivos estão em formato .avi e podem ser acessados no diretório \Videos\Ratio-
nal. Informações complementares poderão ser acessadas no Web site da Rational.
Caso você não tenha um visualizador desses arquivos, poderá instalar o utilitário
RadLight 3.03, que está disponível no CD no diretório \Software\Utilitarios\
RadLight.
F I G U R A 1 1 . 6 9 Rational Project Console Multi-Chart Display

CAPÍTULO 11 315
PS8
Fabricante: Sciforma
Web Site: www.sciforma.com
A PS8 é uma suíte de software de gerenciamento de projetos que auxilia na gestão de
projetos corporativos.
Serão abordados brevemente os seguintes itens:
Gerenciamento de múltiplos projetos
Múltiplas visões
Segurança
Gerenciamento de Insights
Visões na Web
Ferramentas de aprendizado
Extensibilidade de banco de dados
Gerenciamento de portfolio
Gerenciamento do Web site
Visão de Gantt
Integrated Report Writer
Templates de projeto
Nivelamento de recursos
Gerenciamento de custos
Gerenciamento de caminho crítico
Gerenciamento de corrente crítica
E por último serão resumidamente apresentados os módulos adicionais do PS8:
Project Communicator e o PSI.
Sistemas Operacionais: Windows 9x, Windows Me, Windows NT4, Win-
dows 2000 ou Windows XP
Processador: Pentium 120 MHz ou superior
Memória: 32 MB (64 MB é recomendado)
Espaço em Disco: 45 MB
Mouse
Monitor: resolução de 800 × 600 com 256 cores ou superior
Gerenciamento de múltiplos projetos
A arquitetura do PS8 suporta o planejamento de múltiplos projetos utilizando um
conjunto (pool) comum de recursos. Você pode gerenciar projetos individualmente
ou formar um “master project” que contenha múltiplos projetos com suas interde-
pendências.

Múltiplas visões
O PS8 fornece um conjunto de visões (views) para obter informações sobre os proje-
tos. Esse conjunto é composto de:
Project List (um centro de controle de visualização de todos os projetos).
F I G U R A 1 1 . 7 0 Project List
Resource List (informações e edição dos recursos do projeto).
F I G U R A 1 1 . 7 1 Resource List

CAPÍTULO 11 317
Task List (informações e edição de tarefas do projeto).
F I G U R A 1 1 . 7 2 Task List
Gantt Chart (visualização de gráfico de Gannt).
F I G U R A 1 1 . 7 3 Gantt Chart

Network Diagram (exibe o fluxo do seqüenciamento e o do relacionamento das

tarefas do projeto).
F I G U R A 1 1 . 7 4 Network Diagram
Outline Tree (fornece uma visão gráfica da WBS do projeto).
F I G U R A 1 1 . 7 5 Outline Tree

CAPÍTULO 11 319
Distribution Spreadsheet (uma visualização em três painéis que contêm informa-

ções sobre tarefas, recursos e dados de distribuição de recursos).
F I G U R A 1 1 . 7 6 Distribution Spreadsheet
Resource Utilization (visualização em dois painéis da totalização dos tempos e pe-

ríodos de trabalho dos recursos).
F I G U R A 1 1 . 7 7 Resource Utilization

Graph (gráficos de barra e de linha de todas as informações de tempo do projeto).
F I G U R A 1 1 . 7 8 Graph
Reports (acesso on-line a todos os relatórios do PS8).
F I G U R A 1 1 . 7 9 Report

CAPÍTULO 11 321
Segurança
O PS8 adota dois modelos de segurança para proteger as informações do projeto: ba-
seado em logins e senhas e baseado na Access Control List (ACL) do Windows.
Utilizando logins e senhas, você permite ou não o acesso de leitura e gravação aos
elementos do projeto.
Para habilitar o modelo ACL de segurança, será necessária a aquisição do compo-
nente PC-Admin. Esse tipo de recurso se integra com os projetos do PS8 e considera
as políticas de segurança do Windows, bem como as permissões individuais e de gru-
pos de usuários.
No CD que acompanha este livro, você encontrará mais informações sobre segu-
rança (em inglês) no arquivo \Software\PS8\PS8_Seguranca.pdf
Gerenciamento de Insights
Ao observar o status atual de um projeto, você gostaria de voltar no tempo e verificar
informações de status anteriores para capturar as tendências de performance do pro-
jeto? O PS8 fornece justamente esse tipo de insight.
Por exemplo, você pode visualizar um gráfico interativo do status do projeto no
seu browser com as principais milestones do cronograma. Um player control permi-
te que você vá para a frente e para trás rapidamente, a fim de se informar do que
aconteceu em cada período e comparar com o status atual. Além disso, você pode vi-
sualizar relatórios Web que exibem um histórico de tempo das métricas que são im-
portantes para gerar insights na performance do projeto.
O PS8 estendeu seus recursos e incluiu campos históricos organizados por data
(definidos pelo usuário) e um método flexível de definição, chamado cenário de cap-
tura histórica, que descreve quais métricas do projeto são armazenadas nos campos
históricos. Um gerente de projeto pode executar um desses cenários a fim de “logar”
as métricas necessárias para cada atualização no ciclo de vida do projeto. Com o uso
dos relatórios e gráficos, essa informação ordenada por data pode ser visualizada no
formato de que você precisar.
Visões na Web
O PS8 fornece um conjunto de ferramentas para postar as visualizações do projeto
em seu Web site. Essas ferramentas geram automaticamente as páginas Web (in-
cluindo figuras) das visões do projeto.
Adicionalmente, o PS8 gera controles para navegação a fim de visualizar detalhes
de páginas. O PS8 Web Site Manager permite que você controle as ferramentas para
realizar manutenções automáticas de atualização dos gráficos do seu projeto.
Aprendendo e utilizando o PS8

O PS8 é compatível com o Windows, então você já pode iniciar a sua operação em
um ambiente amigável e intuitivo.

O PS8 vem com uma série de guias, wizards (assistentes), dicas do dia, sugestões e
ajuda sensitiva aos campos da interface.
Possui também multiníveis de undo/redo (fazer e desfazer), fornecendo um am-
biente seguro caso alguns erros sejam cometidos, ou caso você queira tentar diversas
alternativas de recursos durante cenários “e-se”.
Um novo sistema de help multipainel Windows 2000 fornece acesso estruturado
à completa documentação on-line.
Além disso, o PS8 inclui um novo manual que ensina os fundamentos do gerencia-
mento de projetos com PS8 através de exemplos simples e consistentes.
Extensibilidade de banco de dados

Você pode adicionar qualquer número de campos customizados às tabelas do banco
de dados relacional do PS8.
O PS8 suporta uma grande variedade de tipos de campo, incluindo memo, rate,
text, integer, yes/no, URL, decimal, decimal distributed, date, duration, cost, $, $
distributed, effort, effort distributed e history dated.
Além disso, você pode definir a quantidade necessária de fórmulas customizadas
para realizar cálculos nos campos padrão e customizados de dados. As fórmulas do PS8
são avançadas com um conjunto completo de funções aritmétricas, strings e datas.
Você pode facilmente referenciar e somar dados de uma tabela para outra no PS8.
Gerenciamento de portfolio
O PS8’s Portfolio Manager provê uma ferramenta para organizar os projetos em
portfolios. Um portfolio consiste em um nome de portfolio, um conjunto de fontes
e uma seleção de projetos.
O PS8 suporta as fontes de diretórios de rede, banco de dados e até um FTP na
Internet ou Intranet. Um simples portfolio pode ser composto de várias fontes.
O Portfolio Manager inclui um filtro para seleção de projetos que permite testar
quaisquer padrões ou projetos customizados para determinar quais projetos vão de
encontro aos critérios de inclusão no portfolio.
Gerenciamento do Web site

PS8’s Web Site Manager fornece um conjunto completo de ferramentas para defini-
ção e atualização automática de múltiplos Web sites de gerenciamento de projetos.
O Web Site Manager usa os seus portfolios definidos como fonte de informação dos
projetos. O PS8 permite que você defina um conjunto de “Web folders” (diretórios) para
cada portfolio e selecione cada relatório ou gráfico a ser incluído nesses diretórios.
Você pode atualizar automaticamente um Web site utilizando o Web Site Mana-
ger para abrir os portfolios, executar os relatórios e automaticamente fazer o FTP
(transferência dos arquivos) para o seu Web site em um servidor Web.

CAPÍTULO 11 323
F I G U R A 1 1 . 8 0 PS8 Portfolio
Você pode escolher o visual do Web site do projeto, porque o PS8 provê controle
extensivo sobre o visual do seu Web site, incluindo estilos de seleção, métodos de
navegação e a utilização de templates (modelos).
Quando for o caso, o Web Site Manager gera um completo log de erros durante
cada atualização.
Visualização de Gantt
O PS8 inclui uma visualização de Gantt baseada em Java que pode ser facilmente in-
tegrada ao Web site do seu projeto. O PS8 fornece vários recursos de visualização
nesta ferramenta.
Integrated Report Writer

O PS8 tem uma poderosa ferramenta de construção de relatórios. Utilizando o Re-
port Writer, você pode definir uma biblioteca de relatórios customizados que po-
dem ser tabulares ou distribuídos por tempo. Cada relatório pode interagir através
de múltiplos níveis do projeto e contém diferentes filtros para cada nível.
O Report Writer fornece acesso completo aos cálculos de fórmulas em cada célu-
la do relatório, permitindo criar valores calculados.

F I G U R A 1 1 . 8 1 Gantt View (Java)
O Report Writer pode criar relatórios para visualização on-line, impressão,

HTML ou XML. O PS8 permite que você controle as fontes, as cores e a separação
de linhas.
Para relatórios HTML, o PS8 Report Writer pode automaticamente gerar uma
overview page que é vinculada às páginas detalhadas. Por exemplo, a página de over-
view pode conter o resumo de múltiplos projetos onde cada projeto listado está vin-
culado às respectivas páginas detalhadas.
Templates de projeto
O PS8 fornece ferramentas de criação e utilização de modelos de projetos (templa-
tes). Se você tem um conjunto de tarefas que são utilizadas repetidamente em proje-
tos, poderá salvá-las num template, removendo as baselines e datas.
Nivelamento de recursos
O PS8 oferece ferramentas de nivelamento de recursos para manter os planos de
projetos viáveis de acordo com as restrições de recursos.
O algoritmo do PS8 suporta nivelamento de simples e múltiplos projetos. O obje-
tivo do algorítimo é criar o menor cronograma possível, dadas as restrições dos re-
cursos.

CAPÍTULO 11 325
F I G U R A 1 1 . 8 2 Nivelamento de recursos – Janela de

configuração
Gerenciamento de custos
O PS8 fornece recursos completos de gerenciamento de custos. O PS8 permite cor-
relacionar os calendários da contabilidade com os calendários dos projetos, além de
ter recursos de conversão de moedas baseados nos fatores de conversão definidos
pelo usuário.
Gerenciamento de caminho crítico

O PS8 oferece suporte completo ao tradicional gerenciamento de caminho crítico.
O caminho crítico é exibido e calculado a cada mudança no cronograma. Opcio-
nalmente, você pode definir estimativas PERT três-pontos (Otimista, Pessimista e
Realista) para a duração das tarefas. O seu plano de projeto pode ser alvo em até cin-
co diferentes baselines para cálculos de valor agregado e variações, custos e variações
no cronograma. A WBS também é suportada, incluindo geração automática de códi-
gos WBS.
Gerenciamento de corrente crítica

O PS8 fornece suporte à moderna técnica de gerenciamento chamada corrente críti-
ca, uma abordagem desenvolvida por Eliyahu M. Goldratt baseada em seus recentes
trabalhos de otimização de produção, em que ele desenvolveu a Teoria das Restri-
ções. O Dr. Goldratt extendeu a Teoria das Restrições para o gerenciamento de pro-
jetos, apresentando-a ao mundo em seu livro entitulado Critical Chain.

O gerenciamento de corrente crítica oferece promissores resultados às organiza-

ções que enfrentam problemas de entregas (deliverables) no tempo de mercado em
indústrias altamente competitivas. Brevemente falando, essa técnica remove o fator
de segurança ou de contigência de cada tarefa. Mais detalhes sobre essa técnica pode-
rão ser acessados no CD, no arquivo \Software\PS8\critical_chain_concepts.PDF.
Project Communicator
A utilização do Project Communicator em conjunto com o PS8 oferece muitos be-
nefícios aos gerentes de projetos e aos membros da equipe do projeto.
O Project Communicator é dividido em dois produtos: PC-Inform e PC-
Objectives. Cada produto é vendido separadamente e pode funcionar independen-
temente um do outro.
A utilização do PC-Inform requer a versão 8.1 ou superior do PS8 já instalada para
o componente PC-Manager. O PC-Objectives pode ser instalado e utilizado inde-
pendentemente do PS8 versão 8.1 ou superior.
Se o PC-Inform e o PC-Objetives forem utilizados juntos, eles compartilharão as
mesmas estruturas e tabelas de banco de dados, provendo fácil configuração e manu-
tenção do sistema.
PC-Inform
Os componentes do PC-Inform são:
Componente gerencial
Componente de equipe
Instalação dinâmica
Facilidade de uso
Redução de erros
Arquitetura aberta de banco de dados
O componente gerencial, ou PC-Manager, é uma forma automatizada de coletar

informações para atualizar o projeto. Ele é utilizado para revisar as informações inse-
ridas pelos membros da equipe do projeto e permite importar essas informações
para o PS8. O PC-Inform Manager Client é acessado diretamente do menu do PS8.
Durante essa importação, você pode aprovar as entradas de tempo, modificar esti-
mativas de trabalho e responder com mensagens aos membros do time do projeto.
Na seqüência dessa revisão, você pode automaticamente atualizar o plano do projeto
com as entradas do time. Completos logs de anotação são mantidos para os membros
do projeto, para revisão no PS8 e geração de relatórios de status.
O componente de equipe, ou team component, é um elemento de apontamento de
horas que fornece aos membros da equipe do projeto acesso às listas de tarefas mais
atualizadas. Os participantes do time podem visualizar suas tarefas semanais e podem

CAPÍTULO 11 327
F I G U R A 1 1 . 8 3 PC-Manager
entrar com as informações de tempo gasto para cada tarefa, digitar notas de status e
ter acesso às estimativas de quanto trabalho ainda falta para terminar as tarefas. A pla-
nilha de apontamento de horas pode então ser aprovada ou rejeitada pelo gerente de
projeto (Figura 11.84).
F I G U R A 1 1 . 8 4 Planilha de apontamento de horas

A instalação do PC-Inform é muito fácil e segue o estilo de assistente no momento

do setup. O PC-Inform pode ser instalado na maioria dos drivers de ODBC compatí-
veis do mercado, incluindo Microsoft Access, Oracle, Sybase SQL Server e Micro-
soft SQL Server. A instalação pode criar automaticamente um banco de dados, inde-
pendentemente se você ainda não tiver estabelecido um.
A interface do PC-Inform é de fácil utilização e muito intuitiva. Uma vez criados
os planos do projeto com o PS8 num repositório de banco de dados, os membros do
time do projeto usam o PC-Inform Team Client para visualizar suas tarefas indivi-
duais e seus prazos, para digitar notas de status e fornecer estimativas de quanto ainda
falta para completar as tarefas. Então, os gerentes podem facilmente avaliar, aprovar
(ou rejeitar), monitorar e realocar o trabalho – tudo antes de exportar os prazos
aprovados no banco de dados do projeto e integrá-los aos respectivos projetos.
Devido ao fato de os dados serem inseridos somente uma vez através de um único
ponto de entrada, o PC-Inform economiza tempo e dimimui a ocorrência de erros.
Isso também aumenta a eficiência administrativa sem abrir mão da oportunidade de
revisar gerencialmente todas as mudanças nos planos de projetos antes de serem
atualizados.
O PC-Inform é baseado em uma tecnologia de banco de dados multiusuário testa-
da, estável e de alta performance. Devido à sua arquitetura aberta de banco de dados,
o PC-Inform pode ser escalado para atingir as necessidades do grupo, do departa-
mento e da organização. PC-Inform vem com os drivers de ODBC para Access, SQL
Server e Oracle.
PC-Objectives
O PC-Objectives tem as seguintes características:
Definição dos objetivos organizacionais

Métricas
Os envolvidos são mantidos informados
Gerenciamento de segurança objetiva
Facilidade de desenvolver
O PC-Objectives permite definir os objetivos da organização de uma maneira

“top-down” usando uma interface familiar, o browser.
Os Originators comunicam os objetivos, enquanto os Producers são responsáveis
por implementar os objetivos.
Você negocia os objetivos com os Producers para definir o tempo e o orçamento
requerido. Dessa forma, todos os projetos são “linkados” (vinculados ou alinhados)
aos objetivos da organização.
As métricas respondem à questão “como está o projeto?”. Uma métrica tem um
valor alvo e percentuais (thresholds) de valores para visualização de status.

CAPÍTULO 11 329
Barra
de Botões Informação
Objetiva
Árvore
de Objetos
Guias
da Janela
Principal
F I G U R A 1 1 . 8 5 Janela do PC-Objectives
O PC-Objective utiliza os thresholds para definição de indicadores de mudança. As

cores utilizadas vão mudando de verde para amarelo e para vermelho quando as res-
trições de cronograma ou de orçamento são ultrapassadas.
Cada objetivo pode conter quantas métricas forem necessárias. Valores de métri-
cas podem ser automaticamente integrados com os custos do projeto e dados do cro-
nograma no banco de dados do projeto do Sciforma PS8; as métricas também podem
ser manualmente inseridas.
Devido ao fato de o PC-Objetives manter um histórico de todos os valores de mé-
tricas reportados, você poderá facilmente verificar as tendências através de visualiza-
ções gráficas das métricas.
Além dos Originators e dos Producers, outros indivíduos autorizados podem receber
permissões de visualização dos objetivos da organização de uma forma familiar e fle-
xível. Cada objetivo mostra o status das métricas utilizando indicadores gráficos. Os
usuários podem navegar através dos níveis de prioridade dos objetivos, desde os mais
altos até os mais baixos. Permissões diferenciadas de acesso podem ser concedidas
pelos Originators.
O PC-Objectives fornece extensivo controle sobre a visibilidade dos usuários
nos objetivos organizacionais do projeto. Um administrador configurará as res-
pectivas permissões e níveis de detalhamento para os indivíduos da organização.
Os tipos de acessos são “None” (nenhum), “View Only” (somente visualizar) e
“Full Access” (acesso total). Usuários com “Full Access” podem ser Originators ou
Producers. Para cada indivíduo, você poderá determinar níveis de permissões da
seguinte maneira:

High: A visibilidade se estende para o objetivo inteiro, incluindo detalhes de

métricas.
Medium: Permite visualizar as definições do objetivo e os status das métricas
(por exemplo: verde, amarelo ou vermelho), mas não permite visualizar os de-
talhes históricos das métricas.
Low: Permite visualizar somente a informação de definição do objetivo. Nenhu-
ma informação sobre métrica estará visível.
None: Permite remover todas as permissões garantidas explicitamente para in-
divíduos ou organizações.
O PC-Objectives utiliza tecnologia Web (Java e XML) para permitir a todos os

usuários interagir com o banco de dados do Project Comunicador utilizando somen-
te um navegador Web. PC-Objetives é um conjunto de arquivos que você instala no
seu Web Server. Essa abordagem elimina a instalação de drivers ODBC e software
de clientes de banco de dados em cada estação e elimina potenciais problemas de ver-
sões de DLLs inconsistentes associadas a versões atuais de banco de dados que nor-
malmente são instaladas nas estações de trabalho.
Além disso, o PC-Objetives trabalha com os mais modernos browsers, sem utili-
zar recursos tais como downloads, plug-ins e outros tipos de software instalados nas
estações do clientes que incomodam o usuário, ou seja, você tem um thin browser.
PSI
Gerentes de projetos podem utilizar o PSI junto com o PS8 para compatilhar infor-
mações com sistemas ERP, mais especificamente o SAP R/3.
O funcionamento do PSI se dá através da tradução dos dados de uma aplicação
para outra, permitindo aos usuários gerenciar as mesmas informações de maneiras
diferentes. Além disso, o PSI permite também a customização das seleções dos dados
a serem transferidos entre as aplicações.
Mais detalhes sobre o PSI podem ser acessados no arquivo \Software\ PS8\Psi.pdf.
Além da suíte PS8, a título de informação, a Sciforma desenvolve um produto
muito interessante utilizado para modelagem ou mapeamento de processos empre-
sariais chamado Sciforma Process. Além disso, o produto permite fazer simulações
animadas dos processos. Mais informações sobre o Sciforma Process estão no arqui-
vo \Software\Sciforma_Process\Visao_Geral_Sciforma_Processv4.pdf.
Você poderá fazer downloads tanto do PS8 quanto do Sciforma Process no site da
Sciforma, em http://www.sciforma.com/products/downloads.asp
Após aceitar o contrato e preencher o formulário no site com os seus dados
pessoais, faça o download dos aplicativos versões trial. Você receberá logo em
seguida um e-mail com o número de série que deverá ser utilizado no momento
da instalação.

CAPÍTULO 11 331
Você poderá utilizar esses produtos, com todas as suas funcionalidades, durante
14 dias, depois as licenças expirarão.
TASSC ESTIMATOR MANAGER

Fabricante: Tassc Solutions
Web Site: http://www.tassc-solutions.com
O Tassc Estimator Manager 2001 é um software para estimativas de custos e

tempo de projetos de desenvolvimento de software.
As estimativas de custos e tempo deste produto são baseadas na “ObjectMatrix”,
uma técnica de estimativa desenvolvida pela própria Tassc Solutions que oferece
uma abordagem baseada em algoritmos, a partir de conhecimentos práticos de mais
de uma década de experiência em projetos de desenvolvimento de software, combi-
nados com um fundamento teórico resultante de cinco anos de experiência em pro-
jetos de pesquisa.
O Tassc Estimator 2001 é um produto com interface muito intuitiva e de fácil
operação, mesmo para usuários novatos.
F I G U R A 1 1 . 8 6 Tassc Estimator Control Bar
A arquitetura do produto permite aos gerentes de projetos entender as estruturas

complexas do projeto e organizar o escopo do projeto de forma bem visual. A arqui-
tetura do produto fornece um estilo de interface do tipo “Explorer” para capturar ou
inserir as informações do escopo do projeto utilizando a UML (Unified Modeling
Language).
O Tassc Estimator 2001 é projetado para suportar o desenvolvimento de software
orientado a objetos, componentes e Web.
Os gerentes de projetos podem especificar o tamanho, o nível de complexidade, a
geneticidade e o reuso associados a cada elemento do escopo e podem designar a tec-
nologia específica para as respectivas classes e/ou scripts.
As informações de escopo podem ser vistas de forma estruturada ou classificada.

F I G U R A 1 1 . 8 7 Visão da arquitetura do projeto de forma classificada
F I G U R A 1 1 . 8 8 Visão da arquitetura do projeto de forma estruturada

CAPÍTULO 11 333
É possível modificar, recortar, copiar, colar, mover, reclassificar e deletar ele-

mentos do escopo.
Um aspecto interessante deste produto é que ele consegue importar o escopo do
projeto de ferramentas CASE, acelerando dessa forma os estágios iniciais de estima-
tiva dos custos e de tempo dos projetos de desenvolvimento. O Tassc Estimator
2001 importa o escopo das seguintes ferramentas:
Popkin System Architect 2001, versões 7.x.
Rational Rose, versões 98i e 2000.
Select Enterprise, versões 5.2, 6.0, 6.1 e 6.4.
TogetherSoft, versões 3.2, 4.0, 4.1, 4.2 e 5.0.
A versão 2002 desse produto deverá importar o escopo do projeto de versões

mais atuais das ferramentas CASE supracitadas.
A seguir, vamos a um exemplo ilustrado de como utilizar o Tassc Estimator 2001.
O gerente pode partir de dois caminhos. Primeiramente, veremos como impor-
tar o escopo de uma ferramenta CASE para facilitar o seu trabalho, evitando a inser-
ção dos elementos do escopo um a um.
1. Clique no ícone da barra principal intitulado “Architecture”. A seguinte tela

será exibida:
F I G U R A 1 1 . 8 9 Janela Architectute

2. Depois selecione o menu “Project” e escolha a opção “Import”. Aparecerá a

janela a seguir com a opção Case Tool já ativada:
F I G U R A 1 1 . 9 0 Janela de
importação de escopo de fer-
ramentas CASE
3. Selecione a ferramenta CASE e a sua respectiva versão. Após informar esses

dados, está na hora de indicar o nome do arquivo do seu projeto. Sem fechar
a janela, selecione a opção “Project” e faça uma busca no diretório onde se
encontra o arquivo do seu projeto gerado pela ferramenta CASE.
F I G U R A 1 1 . 9 1 Janela de
importação do projeto
4. Agora você poderá escolher algumas opções extras em “Settings”, como por
exemplo, automaticamente “Deletar TODOS os escopos do CASE existen-
tes”, caso já tenha importado alguma vez o mesmo projeto. Ou você poderá
manualmente reter ou não os qualificadores do escopo.
F I G U R A 1 1 . 9 2 Janela
de configurações

CAPÍTULO 11 335
5. Depois basta clicar no botão “Import” e aguardar o Tassc Estimator 2001 Mana-
ger para importar todas as classes, bem como as interfaces e os componentes do
seu projeto. Uma observação importante: para importar todos os elementos do
escopo com seus respectivos qualificadores, a opção “Retain my qualifiers” deve
estar ativada na seção manual de “Settings”; caso contrário, todos os elementos
serão importados com valores default (medium) para tamanho, geneticidade,
reuso e complexidade. A figura a seguir ilustra essa opção.
F I G U R A 1 1 . 9 3 Mantendo os qualificadores do seu

projeto
Uma outra forma de começar é “partindo do zero”. Abra o Tassc Estimator 2001 e
selecione “Project”, “New”. Depois clique na opção Architecture e, com o botão di-
reito sobre cada item do menu Explorer, vá criando os itens de escopo. Por exem-
plo, a Figura 11.94 mostra a janela que surge quando criamos um componente.
F I G U R A 1 1 . 9 4 Janela de criação de um novo componente

A Figura 11.95 mostra a janela que surge quando criamos uma nova interface.
F I G U R A 1 1 . 9 5 Janela de criação de uma nova interface
A Figura 11.96 mostra a janela que surge quando criamos uma nova classe.
F I G U R A 1 1 . 9 6 Janela de criação de uma nova classe

CAPÍTULO 11 337
Em relação à orientação a objetos, a Figura 11.97 mostra a janela que surge quan-
do criamos um novo subsistema.
F I G U R A 1 1 . 9 7 Janela de criação de um novo subsistema
A Figura 11.98 mostra a janela que surge quando criamos um novo Use Case.
F I G U R A 1 1 . 9 8 Janela de criação de um novo Use Case

A Figura 11.99 mostra a janela que surge quando criamos uma nova Classe relacio-
nada à orientação a objetos.
F I G U R A 1 1 . 9 9 Janela de criação de uma nova classe
Depois que aprendemos como criar os elementos, vamos configurar as métricas.

Clique no ícone “Metrics” da barra de ferramentas principal. Será exibida a tela da Fi-
gura 11.100.
Nessa tela você pode criar novas linguagens e programação ou escolher linguagens
previamente criadas. Além disso, para cada linguagem, você pode determinar o es-
forço; por exemplo, em Java foi configurado que o esforço de programação seria de
15% a mais, conforme o exemplo anterior. Isso afeta muito na hora do Tassc fazer as
suas estimativas.
Na Figura 11.101 você poderá determinar a produtividade de cada linguagem de
programação baseada na ObjectMatrix ou em outra personalizada por você.
Na opção seguinte temos as métricas de atividades. Você poderá utilizar as métricas
padrão para cada fase do projeto ou então configurá-las de acordo com a sua experiência
de gerenciamento de projetos e de programação. Essas estimativas são feitas por pacotes,
ou seja, baseado em Componentes, Orientação a Objetos, Web ou Personalizado. Para
cada fase, você poderá configurar um percentual, desde que a soma de todas não exceda
100%. O Tassc divide as fases de um projeto em Planejamento, Análise, Design, Cons-
trução, Testes, Integração e Revisão. A Figura 11.102 ilustra essa opção.
As opções de Métricas são uma das configurações mais parametrizadas que o Tassc
possui e influenciam muito nas estimativas; portanto, utilize-as com muito critério.
Lembre-se de que você poderá criar as suas próprias métricas sempre obedecendo
aos critérios de como o Tassc trata as estimativas.

CAPÍTULO 11 339
F I G U R A 1 1 . 1 0 0 Métricas de tecnologia
F I G U R A 1 1 . 1 0 1 Métricas de produtividade


CAPÍTULO 11 341
F I G U R A 1 1 . 1 0 4 Inserindo um Recurso no Projeto
Seguindo com o nosso tutorial, clique no ícone “Team” da barra de ferramentas

principal para inserir os recursos do projeto, assim como o valor de cada um por hora
trabalhada.
Conforme ilustrado, para facilitar, você poderá agrupar os recursos, tais como
fornecedores e equipe do projeto; enfim, todos os envolvidos que, de alguma forma,
custam dinheiro para o projeto.
Para criar um recurso, clique com o botão direito na pasta do time do projeto, por
exemplo, e selecione a opção “New Resource”. Nessa janela você poderá entrar com
as seguintes informações: nome, função, produtividade do recurso, valor hora nor-
mal, valor hora extra, quantos dias úteis o recurso trabalha no mês e quantas horas o
recurso trabalha por dia. Todas essas informações causam grande impacto nas esti-
mativas e devem ser preenchidas também com muito cuidado. A Figura 11.104 ilus-
tra esse recurso.
Outro recurso interessante é o Studio, onde você poderá informar e criar ou-
tros recursos do projeto, tais como materiais de treinamentos, impressos; en-

fim, quaisquer recursos que não sejam recursos humanos. A todos eles você po-
derá associar um custo ou um esforço. Por exemplo, suponhamos que durante o
projeto seja necessária a aquisição de um software ou de um plug-in, então você
insere essa informação para o Tassc computar o custo desse software nas estima-
tivas. Para facilitar, você poderá agrupar esses materiais. A Figura 11.105 ilustra
esse conceito.
F I G U R A 1 1 . 1 0 5 Inserindo um novo material no projeto
Você pode também informar os riscos do projeto, bem como seus percentuais de
probabilidades, impactos, definições e descrição das ações de contingência. Para fa-
cilitar, os riscos poderão ser agrupados conforme a Figura 11.106:
F I G U R A 1 1 . 1 0 6 Inserindo informações de riscos no projeto

CAPÍTULO 11 343
Depois de configurados todos os elementos que envolvem o ambiente do projeto,

ou seja, a arquitetura, as métricas, os recursos humanos, os materiais e os riscos, é
hora de verificar tudo. Clique no ícone “Estimator” da barra de ferramentas principal
e visualize as estimativas de tempo e custo geradas pelo Tassc Estimator Manager
2001. A Figura 11.107 ilustra as estimativas.
F I G U R A 1 1 . 1 0 7 Resultado das estimativas
A partir das estimativas, você pode gerar alguns gráficos interessantes conforme
as Figuras 11.108, 11.109 e 11.110.
F I G U R A 1 1 . 1 0 8 Optimum Resource Graph

F I G U R A 1 1 . 1 0 9 Costs Graph
F I G U R A 1 1 . 1 1 0 Risk Contingency Graph
O Tassc vai além desses gráficos e permite a importação dos resultados para um
arquivo em formato de texto ou de forma mais sofisticada, para o Excel. As Figuras
11.111 e 11.112 ilustram os recursos.
E, por último, o ícone Process permite criar, definir e customizar os processos de
desenvolvimento de software (por fases e interações) para acompanhar e monitorar
os procedimentos organizacionais do desenvolvimento de sistemas (Figura 11.113).

CAPÍTULO 11 345
F I G U R A 1 1 . 1 1 1 Resultado das métricas para arquivo em formato texto
F I G U R A 1 1 . 1 1 2 Tela de configuração para exportar

resultado das métricas para o MS-Excel

F I G U R A 1 1 . 1 1 3 Processos de desenvolvimento
No CD que acompanha este livro, você poderá instalar e utilizar o Tassc Estimator
Manager por 21 dias. Você deverá solicitar uma licence-key para o pessoal da Tassc.
Execute o setup que está no diretório \Software\Tassc. Depois de instalado, execu-
te o programa. A seguinte tela aparecerá:
F I G U R A 1 1 . 1 1 4 Solicitação de Licence Key

do Tassc Estimator Manager 2001

CAPÍTULO 11 347
Se você receber a informação de que a licença expirou, não se preocupe, pois você
pode pedir uma extensão por somente mais 21 dias. Clique no botão “Extend Evalu-
ation”. A seguinte tela surgirá:
F I G U R A 1 1 . 1 1 5 Form para preenchimento de

dados para solicitação da Extend Evaluation
do Tassc Estimator Manager
Após preenchimento dos dados, clique no botão OK e surgirá a seguinte tela:
F I G U R A 1 1 . 1 1 6 Arquivo de licença estendida do Tassc Estimator Manager

Digite o nome TEConfig.lic. Pronto, o arquivo está salvo. Depois, envie esse ar-
quivo anexado por e-mail ao suporte da Tassc solicitando a sua Extend Licence Key
para utilização de todas as funcionalidades do Tassc Estimator Manager 2001 por 21
dias. O e-mail do suporte da Tassc é licensing@tassc-solutions.com. A tela a seguir
surge logo depois que você salva o arquivo:
F I G U R A 1 1 . 1 1 7 E-mail para envio da Extend License Key
Depois pressione o botão OK e envie o e-mail com um pequeno texto solicitando

a Extend Key e anexe o arquivo TEConfig.lic no e-mail. Em poucos dias (ou depen-
dendo até no mesmo dia), você estará recebendo a Extend Licence Key para utiliza-
ção do Tassc Etimator Manager 2001.
Para habilitar a utilização dos 21 dias do Tassc, execute novamente o Tassc e depois
informe a chave (key) que você recebeu no e-mail de resposta pressionando o botão
“Extend Evaluation”. Surgirá uma pergunta indagando se você já recebeu um código
de desbloqueio, desta forma:
F I G U R A 1 1 . 1 1 8 Pergunta de confirmação de rece-

bimento de código de desbloqueio do Tassc
Responda Sim (Yes) à pergunta. A seguinte tela surgirá:
F I G U R A 1 1 . 1 1 9 Entrada do novo código de licença

CAPÍTULO 11 349
Informe a chave (key) que você recebeu no e-mail de resposta (copie e cole) e
pressione o botão OK. Agora você estará apto a utilizar o Tassc Estimator Manager
2001.
Versões Atuais do Tassc Estimator

As versões 2005 e 2006 do Tassc Estimator foram disponibilizadas para download no
site da Tassc Solutions após o lançamento da primeira edição deste livro. Você en-
contrará no CD que acompanha este livro, na pasta \TASSC\Aplicativos\, estas
versões para testar e verificar as novas funcionalidades. As estimativas continuam,
porém ainda mais parametrizadas.
Spider Project
Fabricante: Spider Management
Web Site: http://www.spiderproject.com – em idioma russo.
Contatos no Brasil:
http://www.spiderproject.com.br
info@spiderproject.com.br
spider@spiderproject.com.br
Tel: 55-61-8153-8290
A Spider Management Technologies é uma empresa líder em consultoria na área

de Gestão de Projetos na Rússia, com forte atuação em diversos países na Europa e
Oriente. As atividades da empresa cobrem os seguintes pontos:
Desenvolvimento e implementação de sistemas de gestão de projetos

Treinamento em Gestão de Projetos
Desenvolvimento e comercialização de uma ferramenta única para gestão pro-
fissional de projetos – Spider Project
Sobre o Spider Project

O software Spider Project é uma ferramenta extremamente potente para a imple-
mentação de tecnologias relacionadas à gestão de projetos. O que a Spider Manage-
ment implementa não é apenas um pacote de software, mas uma tecnologia abran-
gente que inclui desenvolvimento organizacional, treinamento de pessoal, coleta e
processamento de informações e outras peculiaridades que apenas um sistema com-
plexo de gestão de projetos pode fornecer.
Seus clientes incluem o Ministério da Defesa Russa, o Fundo de Propriedade Fe-
deral Russo, o Banco de Crédito de Moscou, Companhia de Óleo e Gás Tyumen e
muitas outras empresas na área de construção, petróleo e gás, construção naval, de-
senvolvimento de software, entre outros.

Spider Project não é usado apenas pelos russos, mas também por empresas nos
Estados Unidos, Hong Kong, Alemanha e Holanda. Sua primeira versão foi lançada
em 1992 e em 1993 foi apresentada na Alemanha (Leipzig e Munique). Desde aquela
época, o pacote tem sido constantemente melhorado e hoje tem funcionalidades não
disponíveis em nenhum outro software de gestão de projetos.
A construção da Vila Olímpica para os Jogos da Internacionais da Juventude em
Moscou foi o evento que deu maior projeção para o Spider Project. Ele foi considera-
do o projeto de construção mais importante na Rússia em 1997 e tem sido utilizado
como padrão de eficiência em todo o mundo
O Spider é um Sistema de Informação de Projetos desenvolvido para o planeja-
mento e controle de projetos de média e grande envergadura. Além de oferecer
acesso às ferramentas tradicionais (Gantt, cronogramas etc.), o Spider oferece ins-
trumentos para a aplicação de técnicas relacionadas à corrente crítica (limitações de
recursos financeiros, pessoal ou tempo). O Spider permite o controle sobre proje-
tos, programas e portfolios e promove a centralização de métricas de projeto em
uma organização.
O Spider Project foi utilizado em grande projetos, tais como: construção da Vila
Olímpica para o 1st International Youth Games, em Moscou, construção de gasodu-
tos (Caspian Pipeline, Blue Stream, Yamal e Oeste Europeu), construção de fábricas
de alumínio na Rússia (Sayanogorsk, Taishet, Timan) e de hidrelétricas e gestão de
dezenas de projetos na área de defesa da Rússia.
Recursos do Spider Project:
Múltiplas ferramentas integradas: Alinhamento entre cronogramas, Gantt,

gráficos, EAPs (WBS) e muito mais.
EAP em áreas de domínio: A partir da visão da rede de diagramas, uma
EAP/WBS (Estrutura Analítica de Projetos) pode ser vista como um conjunto
de domínios com seus subdomínios. A ferramenta permite que diagramas de
rede sejam construídos para cada subdomínio (Diagrama de rede integrado à
WBS/EAP).
Interface do programa: Gerenciamento de múltiplos projetos ou portfolios.
Controle financeiro, RH, cronogramas, métricas, materiais, fluxos de ativida-
des e processos.
Compartilhamento de Recursos: Recursos (materiais e pessoas) podem ser ad-
ministrados a partir de um repositório centralizado; criação de equipes de pro-
jeto; identificação de turnos; cálculos a partir de métricas corporativas e/ou re-
gistros individualizados; banco de métricas.
Modelagem Computacional: Desenvolvimento de modelos computacionais
(simulação de processos; simulação de alternativas gerenciais e identificação da
melhor solução).

CAPÍTULO 11 351
Arquivos de Projeto: Históricos (qualquer número de versões de cada projeto;

habilidade para comparar versões; criação de linhas de base sem limites de nú-
mero; elaboração de caminhos alternativos “what-if”, ou múltiplos cenários).
Análise de Probabilidades de Sucesso: As tendências de sucesso oferecem ao ge-
rente de projetos informações importantes para assumir riscos e estabelecer as
atividades corretivas necessárias.
Uso de Recursos: Recursos disponíveis podem ser adicionados a partir de qual-
quer tarefa. O Gantt pode ser utilizado para identificação e acompanhamento.
Sem limites: Projetos reais com mais de 200.000 linhas de planejamento. A es-
trutura de dados do sistema permite crescimento ilimitado.
Cronogramas Otimizados: O sistema de restrições utilizado pelo Spider leva
em consideração ainda mais variáveis do que os divulgados na Teoria das Restri-
ções ou corrente crítica, oferecendo cronogramas otimizados por restrições
em níveis superiores à concorrência; o Spider também mostra quais atividades
são críticas por conta do cálculo em corrente crítica.
Sistema de Gerenciamento Corporativo: Os cronogramas de projeto são ba-
seados em um repositório centralizado de normas corporativas, permitindo
maior controle sobre projetos, programas e portfolios.
Gerenciamento de Recursos: Cronograma baseado em habilidades, criação de
equipes de projeto por perfil, simulação de trabalhos com turnos, entre outros.
Gerenciamento de Fluxo de Caixa: Fluxo de caixa; utilização de materiais.
Controle sobre turnos (diversas equipes em um único projeto).
Relatórios não-convencionais: Relatórios exclusivos com análise de resultados
relacionados à corrente crítica ou balanceamento de cronogramas.
Simulação de Riscos: Cálculo de reservas de contingência necessários. Deter-
minação de metas de projeto com margem de confiança.
Arquivos de Projeto e Análise de tendências: Versionamento ilimitado de pla-
nos de projeto com Comparativos entre versões. Análise de tendências para os
principais parâmetros de projeto.
Gestão da probabilidade de sucesso: As tendências de probabilidade de sucesso
sugerem os melhores caminhos para atender diversas análises de performance
em um projeto.

Telas do Spider Project
F I G U R A 1 1 . 1 2 0 Alinhamento entre cronogramas, Gantt, gráficos, EAPs (WBS)
FIGURA 11.121 Alinhamento entre cronogramas, Gantt, gráficos, EAPs (WBS)

CAPÍTULO 11 353
FIGURA 11.122
Rede de diagramas vista como
um conjunto de domínios com
seus subdomínios
FIGURA 11.123 Diagramas de rede construídos para cada subdomínio

FIGURA 11.124 Gerenciamento de múltiplos projetos ou portfolios
FIGURA 11.125 Exemplo de cronograma

CAPÍTULO 11 355
FIGURA 11.126 Estrutura de ciclo de vida
FIGURA 11.127 Estrutura de responsabilidades
FIGURA 11.128 Simulações

FIGURA 11.129 Fluxo de caixa
FIGURA 11.130 Projetos e documentos

CAPÍTULO 11 357
FIGURA 11.132 Tendências e probabilidades de sucesso

FIGURA 11.133 Análise de probabilidade de sucesso
FIGURA 11.134 Identificador de usuários

CAPÍTULO 11 359
FIGURA 11.135 Gantt utilizado para identificação e acompanhamento.
FIGURA 11.136 Plano de investimento

FIGURA 11.137 Gantt de atividades – por tipo de trabalho
FIGURA 11.138 Materiais e custo por volume

CAPÍTULO 11 361
FIGURA 11.139 Gantt de atividades – investimentos
FIGURA 11.140 Diagrama linear

FIGURA 11.142 Simulações da melhor alternativa

CAPÍTULO 11 363
Spider Management Technologies no Brasil

A partir dos trabalhos de Vladimir Liberzon em vários congressos internacionais do
PMI, a Spider MT ganhou visibilidade internacional e está expandindo sua área de
atuação com a abertura de escritórios e novas parceriais em todo o mundo.
As atividades da Spider MT começam no Brasil para o final do segundo semestre
de 2006 e em breve este site estará totalmente traduzido para o português com novi-
dades sobre a empresa e o Spider Project.
Um primeiro ciclo de apresentações sobre a capacidade da ferramenta foi apre-
sentado para convidados selecionados após a realização do 1º Seminário de Gerencia-
mento de Riscos do Distrito Federal, ocorrido nos dias 20 e 21 de junho de 2006, onde o
sr. Vladimir Liberzon foi um dos palestrantes, ocasião em que começou a treinar
uma equipe de suporte no Brasil. O seminário foi realizado pela X25 Treinamento e
Consultoria (www.x25.com.br) e reuniu participantes provenientes das mais variadas
regiões do Brasil, com a participação de diretores, gerentes de projetos e PMOs de
empresas como a Receita Federal, Petrobrás, Vale do Rio Doce, Renner, Brisa, Po-
litec, Cast, Exército Brasileiro, Ministério da Saúde, Banco Central e muitas outras.
Palisade @RISK 4.5, Decision Tools e @RISK for Project

Fabricante: Palisade
Web Site: http://www.palisade.com
Contatos no Brasil:
http://www.sb2.com.br
vendas@sb2.com.br
Tel: +11 3531-6575
@Risk
Tomar uma decisão incorreta é muito fácil quando não é feito um trabalho de análise
das possibilidades e cenários. E essas decisões geralmente são baseadas nas informa-
ções que você tem nas mãos – histórico de custos, preço da concorrência, estimati-
vas dos fornecedores etc. O @Risk lhe permite visualizar todos os resultados possí-
veis de uma decisão, indicando a probabilidade de cada uma ocorrer. Assim, você
terá a disposição todas as informações necessárias para optar pela melhor alternativa,
calculando o risco existente e o que poderá ser evitado. Nenhum software pode pre-
ver o futuro, o @Risk lhe permite escolher a melhor estratégia com base nas infor-
mações disponíveis.
Confira alguns recursos:
O @Risk utiliza uma técnica de simulação denominada Monte Carlo, permitindo
mostrar todos os resultados possíveis. A realização de uma análise no @Risk está di-
vidida em três passos:

1. Defina a incerteza – Comece substituindo os valores duvidosos de sua plani-

lha pelas funções de distribuição de probabilidade do @Risk. Essas funções
apenas representam uma escala dos valores possíveis que a célula poderia as-
sumir em vez de limitar-se a apenas um valor.
2. Selecione seus objetivos – A seguir, selecione as células das quais você está
interessado em saber o valor. Esta célula pode ser o lucro gerado pelo lança-
mento de um novo produto, a taxa de aumento do seu seguro, enfim qual-
quer resultado.
3. Simulação – Depois de realizar os passos anteriores, basta clicar em “Simula-
ção”. É simples! O @Risk irá calcular centenas ou milhares de vezes o seu
modelo de planilha. Não há nenhum limite para o número de cenários dife-
rentes que você pode realizar em suas simulações. Cada vez que você alte-
rar, o @Risk irá calcular os valores aleatórios e exibir o resultado. Com esse
resultado, você terá uma idéia da probabilidade que eles poderão ocorrer.
O poderoso recurso Monte Carlo disponibiliza as probabilidades de uma simu-

lação. Ao realizar uma simulação, o @Risk examina a sua planilha e em vez de exi-
bir um resultado, você terá acesso a milhares de possibilitades. Com o @Risk você
poderá responder a perguntas como “Qual a possibilidade do lucro exceder
R$1.000.000?” ou “Qual a probabilidade que eu perca dinheiro no investimento?”.
Decision Tools
Decision Tools é um conjunto integrado de produtos projetados para trabalhar com
uma série de recursos, fornecendo uma análise combinada e uma série de funcionali-
dades em apenas um único pacote! Decision Tools reúne até sete produtos: @RISK,
Precision Tree, TopRank, RiskOptimizer, BestFit, RISKview e o @RISK Accelera-
tor. Sua instalação rápida e fácil é feita através de apenas um único CD. Esses progra-
mas foram projetados para trabalhar juntamente com um ambiente integrado, per-
mitindo utilizar um conjunto de barras de ferramentas comuns ao Microsoft Excel.
Com o Decision Tools, você pode executar uma análise avançada que nem sempre
pode ser executada em outros softwares. Crie uma árvore de decisão utilizando o
Precision Tree, depois utilize o @RISK para criar uma análise de risco. Após esse
processo, transfira esses dados armazenados em uma outra área de trabalho e utilize
o BestFit para pesquisar e distribuir seus ajustes de dados, permitindo realizar a dis-
tribuição com o @Risk.
Confira alguns recursos do Decision Tools:
Recursos avançados que compõem o @RISK incluem uma maior precisão,

permitindo uma análise completa do cenário, além de possibilitar criar gráficos
de superposição e gráficos com múltiplos sumários.

CAPÍTULO 11 365
O Decision Tools fornece os recursos do @RISK totalmente integrados com o

RISKview 4.5, permitindo assim visualizar a distribuição dos seus dados, além
da possibilidade de utilizar o BestFit para o melhor ajuste dessa distribuição.
@RISK 4.5 trabalha até dez vezes mais rápido que as versões prévias, além de
incluir uma interface de estilos do Microsoft Office.
RISKOptimizer (Industrial Edition)

RISKOptimizer fornece recursos de simulação e de otimização para o Excel. Permi-
te aperfeiçoar seus modelos do @RISK, possibilitando encontrar a melhor solução
possível e sem erros de execução. RISKOptimizer combina recursos de otimização
de algoritmos com os recursos de simulação da ferramenta Monte Carlo, encontran-
do a melhor combinação de fatores para conduzir a um resultado desejado. Por
exemplo, você poderia encontrar uma ótima combinação para seus projetos a fim de
maximizar os lucros de sua empresa.
BestFit
BestFit é a melhor solução de distribuição para o Windows. Permite transferir seus
dados (até 100.000 pontos ou pares), além de definir a função de distribuição que
melhor se ajusta a seus dados. BestFit aceita três tipos de dados: amostral, densidade
e cumulativo, e testa até 26 distribuições utilizando algoritmos de otimização avan-
çados. Com esse recurso, são exibidos resultados graficamente ou através de um re-
latório estatístico, incluindo os ajustes estatísticos que você escolheu.
BestFit oferece um controle completo sobre seus próprios parâmetros, oferecen-
do gráficos novos e uma interface com estilos personalizados. Pode ser utilizado di-
retamente no @RISK, TopRank, ou nos modelos do PrecisionTree.
@RISK Accelerator
Aumenta a velocidade de execução de grandes simulações utilizando todos os recur-
sos de sua CPU. Através de um processo multi-CPU, se o seu PC possuir dois pro-
cessadores, suas simulações serão quase duas vezes mais rápidas! Com uma completa
integração, o @RISK Accelerator possibilita aproveitar a velocidade de um proces-
sador adicional disponível a partir dos recursos de multiprocessamento que estão
cada vez mais populares.
Decision Tools fornece três versões: Standard, Professional e Industrial. Todas as
versões incluem o @RISK 4.5 Professional, BestFit 4.5 e Riskview 4.5. A versão
Standard adiciona a versão padrão do TopRank e do PrecisionTree, enquanto as ver-
sões Professional e Industrial incluem as versões profissionais desses programas. Deci-
sion Tools Industrial adiciona o RISKOptimizer Industrial como também o @RISK
Accelerator para utilizar todos os processadores disponíveis em uma única máquina
durante a simulação.

Kidasa Milestones Professional 2006

Fabricante: Kidasa
Web Site: http://www.kidasa.com
Contatos no Brasil:
http://www.multidoc.com.br/
Tel +55 (19) 3233-6123
Fax +55 (19) 3235-3588
Email: info@multidoc.com.br
O Milestones Professional 2006 é um software de gerenciamento de projetos

que permite:
Gerenciar grandes projetos e coordenar equipes. Ele gera um resumo dos cro-
nogramas da equipe usando um cronograma master, acessa todos os documen-
tos do projeto através de um cronograma “hub” e verifica todas as datas-chave
em múltiplos cronogramas e um único cronograma.
F I G U R A 1 1 . 1 4 3 Combinação de Cronogramas em Cronograma Master

CAPÍTULO 11 367
Utilizar uma gama de layouts flexíveis e permite aplicá-los em cronogramas, fa-

cilitando na visualização e apresentação dos mesmos. Você tem o controle
completo para utilizar símbolos, conectores, layouts de páginas, estilos de tex-
tos, estilo de títulos, temas em cores, gráficos e diversas opções de impressão.
F I G U R A 1 1 . 1 4 4 Customização de Relatórios
Calcular e apresentar graficamente o valor agregado dos projetos, incluindo

BCWP, BCWS, ACWP, SV, CV, CPI e SPI.
F I G U R A 1 1 . 1 4 5 Relatório de Valor Agregado

Através de um assistente criar páginas HTML e gráficos de um cronograma ou

uma hierarquia de cronograma interligados.
F I G U R A 1 1 . 1 4 6 Assistente HTML do Milestones Professional
Criar apresentações coloridas a partir do Microsoft Project e mantê-las sempre

atualizadas.
F I G U R A 1 1 . 1 4 7 Exemplo 1 – Gráfico de Valor Agregado

CAPÍTULO 11 369


CAPÍTULO 11 371

F I G U R A 1 1 . 1 5 4 Exemplo 1 – Gráfico de Gantt

CAPÍTULO 11 373


CAPÍTULO 11 375
F I G U R A 1 1 . 1 6 0 Exemplo 1 – Gráfico de Marcos


CAPÍTULO 11 377


CAPÍTULO 11 379
F I G U R A 1 1 . 1 6 8 Exemplo 1 – Gráfico de Resumos


CAPÍTULO 11 381

F I G U R A 1 1 . 1 7 4 Exemplo 1 – Gráfico de Performance

CAPÍTULO 11 383

F I G U R A 1 1 . 1 8 0 Exemplo 1 – Gráfico de Recursos

CAPÍTULO 11 385

No CD que acompanha este livro, você encontrará uma versão de demonstração

do Milestones Professional 2006 e do Milestones Viewer 2066: diretório \Kidasa\Aplica-
tivos\.

CAPÍTULO 11 387
CONCLUSÃO
Todos os aplicativos apresentados neste capítulo se adequam e podem se apoiar no
gerenciamento de projetos de tecnologia da informação e em projetos de outras na-
turezas.
Foram apresentados, nesse universo de soluções, apenas alguns exemplos e so-
mente as características básicas dos aplicativos.
As informações aqui expostas foram extraídas dos sites dos fabricantes. O mês de
referência das informações é janeiro de 2006. Talvez, na publicação deste livro, al-
gumas informações não estejam atualizadas. Também é possível que novas versões já
tenham sido lançadas com novos recursos e preços diferentes. Portanto, sugiro que
você faça constantes visitas aos sites dos fabricantes para observar tais evoluções e
para pesquisar maiores detalhes sobre os produtos.
Para pesquisar outros produtos, faça uma visita ao site http://www.gantthe-
ad.com/tools-directory/, uma comunidade on-line para gerentes de projetos de TI.
Quando chegar lá, clique no link “Search our Tool Database”, a tela apresentada na
Figura 11.120 será exibida.
Escolha uma ou mais opções da lista e clique no botão “Search”. Ou, se preferir,
digite o nome do aplicativo no campo “Search for”: e clique no botão “Search”. Será
exibida uma lista com os aplicativos que atendem aos critérios da sua pesquisa de
acordo com as opções selecionadas. Nesse site você encontrará uma das listas mais
completas de ferramentas de apoio à gerência de projetos, além de ser uma das prin-
cipais comunidades on-line e pontos de encontro virtuais dos gerentes de projeto de
Tecnologia da Informação.
F I G U R A 1 1 . 1 8 5 Site Gantthead – Busca de aplicativos de gestão de projetos

É importante que a adoção e aquisição de ferramentas computadorizadas de ge-

renciamento de projetos sejam sempre consideradas pelas organizações, pois agili-
zam a tomada de decisões e auxiliam muito o gerente de projetos e sua equipe em sua
nobre função de gerenciar as informações do projeto na ponta dos dedos.
No próximo capítulo, você, gerente de projetos, perceberá que pode ir além da
sua nobre função.

CAPÍTULO 12
Fomentando projetos de tecnologia

da informação na organização
INTRODUÇÃO
Neste capítulo você encontrará sugestões para ajudá-lo a avaliar e justificar a realiza-
ção de alguns projetos de tecnologia da informação e afins na sua organização.
O intuito é apresentar um pequeno guia de conceitos e uma visão geral dos proje-
tos, além de seus produtos e benefícios. Dessa forma, você poderá identificar os po-
tenciais projetos na organização e fomentar suas execuções.
Normalmente, os projetos de tecnologia da informação são divididos em três gru-
pos: estratégicos, de infra-estrutura e de desenvolvimento de software.
PROJETOS ESTRATÉGICOS
Os projetos estratégicos fornecem os processos necessários para alinhar a tecnologia
da informação com as prioridades, necessidades e os objetivos de negócio da organi-
zação. Alguns desses projetos são:
IT Governance
Modelagem de Processos Empresariais
Visão de Processos de Negócio
Melhoria e Redesenho de Processos
Gerenciamento de Processos
Pré-ERP

IT Governance
Com base na visão por processos da organização e das informações manipuladas por
eles, os projetos de IT Governance, mais conhecidos no Brasil como projetos de Ali-
nhamento da TI, fornecem um método objetivo e formal para estabelecer priorida-
des de modo que os recursos de TI sejam administrados para suportar de forma efeti-
va os objetivos da organização.
O tratamento da informação precisa ser visto como um recurso da organização.
Deve ser planejado, administrado e controlado de forma eficaz, desenvolvendo apli-
cações com base nos processos, garantindo que mudanças organizacionais não afe-
tem os sistemas de informação, preservando o investimento realizado.
Geralmente os produtos desse tipo de projeto incluem:
Modelo conceitual de dados

Matriz arquitetura de informação
Matriz arquitetura de sistemas
Portfolio de sistemas
Entre os benefícios desse tipo de projeto, estão os seguintes:
Permite que a TI “fale” a mesma linguagem do negócio da organização.

É um ferramental dinâmico que permite refletir e absorver com flexibilidade e
rapidez as mudanças ocorridas.
Controla o número de ilhas tecnológicas.
Aumenta a satisfação do usuário.
Viabiliza o desenvolvimento de sistemas localizados, bem como a aquisição de
pacotes, mantendo a integridade da informação.
Proporciona visão antecipada das aplicações de que o usuário necessita, fazendo
com que a área de TI tenha atitude proativa.
A partir dessas arquiteturas, os sistemas organizacionais estarão voltados aos
processos.
Modelagem de Processos Empresariais

A Modelagem de Processos Empresariais é o processo de conduzir a melhoria dos
processos de negócio da organização, otimizando a utilização de seus recursos e per-
mitindo criar condições para acompanhar a sua performance e o cumprimento de
suas metas.
Esse serviço faz com que a organização esteja apta a gerenciar mudanças com agili-
dade e segurança, aumentando o desempenho da organização, através da simplifica-
ção e otimização de processos.
Independentemente de seu porte, a organização que implementa um projeto de
Modelagem de Processos Empresariais tem geralmente os seguintes benefícios:

FOMENTANDO PROJETOS DE TECNOLOGIA DA INFORMAÇÃO
CAPÍTULO 12 391
Redução de custos
Redução do tempo de execução
Melhoria da qualidade
Aumento de produtividade
Maior foco na satisfação dos clientes internos e externos
Agilidade no gerenciamento de mudanças
Maior compreensão da organização
A seguir, temos uma ilustração das etapas de um projeto de modelagem de pro-

cessos:
Visão de processos de negócio

A visão de processos de negócio tem como objetivo obter a estruturação dos proces-
sos de negócio da organização de acordo com a visão de desenvolvimento de seus
produtos e serviços.
Com base nessa visão, é elaborada uma análise da situação frente à arquitetura do
negócio, identificando as disfunções.
Normalmente, os produtos a serem entregues são:
Identificação dos processos-chave e de suporte
Definição e descrição de cada processo
Arquitetura de negócio
Análise das disfunções
Processos priorizados para estudo de melhorias
Catálogo dos recursos de TI
Alguns dos benefícios são:

Obter uma maior compreensão da organização.
Racionalizar e garantir o fluxo de informações.
Eliminar processos e atividades redundantes e que não agregam valor.
Oferecer suporte para a análise de aderência de pacotes de sistemas às necessi-
dades da organização.
Servir como base para: análise de partes ou aspectos da organização; simulação
do funcionamento da organização; tomada de decisão sobre operações e orga-
nização da empresa; padronização e otimização da documentação; suporte à
certificação ISO e utilização como ferramenta de gestão administrativa.
Melhoria e redesenho de processos

Com base na visão por processos da organização, no estabelecimento das metas e re-
gras de negócio, efetua-se a análise das disfunções, objetivando a melhoria localizada
do processo ou redesenho com conseqüente melhoria da cadeia de processo.

O resultado desse serviço é melhoria da qualidade, redução de custos, redução do

tempo de execução e simplificação das praticas de negócio.
Normalmente esse serviço gera os seguintes produtos:
Análise das Disfunções

“Should Be”
Indicadores de Desempenho
Estratégias de Transformação
Dentre os benefícios desse tipo de projeto estão:
Promover o entendimento do processo em questão por todos os envolvidos,

identificando pontos fortes e fracos e fatores críticos de sucesso.
Racionalizar o fluxo das informações.
Minimizar os atrasos.
Maximizar o uso de recursos.
Identificar papéis e responsabilidades.
Definir pontos de controle (milestones).
Melhoria da qualidade.
Gerenciamento de processos
Com base na visão por processos e nas metas estabelecidas pela organização, o objeti-
vo desse tipo de projeto é prover um método efetivo para o gerenciamento do fluxo
da informação no processo, estabelecendo itens de controle e medições apropriadas.
Os itens de controle são características mensuráveis por meio dos quais um processo
é gerenciado.
Quando um item de controle não atinge o nível desejado, o processo está com al-
gum problema. A metodologia de gerenciamento deve prever metas de manutenção
e melhorias do processo.
A escolha correta das ferramentas de gerenciamento, itens de controle e pontos
de controle (milestones) impede que ocorra a epidemia do problema no processo,
uma vez que o fato pode ser imediatamente informado ao grupo de origem do pro-
blema.
Normalmente se espera desse tipo de projeto os seguintes produtos:
Indicadores e metas para manutenção e melhoria

Metodologia para avaliação de desempenho
Documentação do fluxo da informação do processo

CAPÍTULO 12 393
Dentre os benefícios estão:
Monitoramento do desempenho da equipe

Garantia da estabilidade do processo
Diagnóstico efetivo do processo
Pré-ERP
A utilização de sistemas ERP é uma poderosa opção para organizações que desejam
construir um sistema de informações integrado.
No entanto, esses sistemas criam uma organização não mais voltada às tarefas, mas
sim a processos contínuos. Por isso, a fase de revisão e análise dos processos da orga-
nização é fundamental.
Para poder executar as mudanças necessárias à linearização e condensação das ati-
vidades, é importante o entendimento do negócio com a visão dos processos.
Alguns aspectos comprometem o sucesso de implementação de sistemas ERP,
para os quais a organização deve atentar:
A não-realização de um projeto de pré-ERP.

A falta de empenho e/ou motivação de todos os níveis da organização e envolvi-
dos no projeto.
Com base na visão por processos da organização, é possível elaborar uma lista de
requisitos para avaliar o grau de aderência, customização, parametrização e/ou mu-
dança de procedimentos necessários, frente ao ERP a ser analisado, bem como dimi-
nuir tempos e custos de implementação.
Os produtos normalmente esperados e entregues deste projeto são:
Fluxo de atividades de todos os subprocessos envolvidos

Lista de requisitos funcionais e técnicos
Modelo de dados conceitual de todos os subprocessos envolvidos
Catálogo dos recursos da informação
Tabela de referência cruzada dos processos versus áreas funcionais
Dentre os benefícios desse tipo de projeto estão:

Suporte para análise de aderência de pacote de sistemas às necessidades da orga-
nização, obtendo antes da implantação a visualização da aderência e o auxílio na
escolha do ERP.
Durante a implantação, a redução de tempo e custos de implantação e a utiliza-
ção da documentação gerada para treinamento.

Após a implantação, a produção de relatórios e interfaces e a preservação do

know-how.
Disponibilização da documentação em intranet.
Redução de aproximadamente 30% no tempo de implantação dos módulos.
Essa redução no tempo implica também a redução no custo da implantação, le-
vando-se em consideração o valor/hora da consultoria que estará associado ao
projeto de implantação do ERP e ao tempo da equipe interna envolvida no pro-
cesso.
Identificar rapidamente a participação das áreas funcionais nos processos da or-
ganização (quem são os verdadeiros executores e responsáveis por quais pro-
cessos e, se houver uma alteração num processo específico, quais áreas funcio-
nais devem ser envolvidas).
Assegurar uma implantação dos módulos de forma estruturada e sem “trau-
mas”.
PROJETOS DE INFRA-ESTRUTURA
Os projetos de infra-estrutura atuam diretamente monitorando a camada mais críti-
ca e vital por onde trafegam todas as informações corporativas, confidenciais e estra-
tégicas das organizações: a rede.
Monitorar significa vigiar, tomar conta. Para isso, contamos com ferramentas de
gerenciamento de redes de altíssima tecnologia capazes de ficar o tempo todo “escu-
tando” e vigiando o comportamento de um servidor ou de um dispositivo da rede e
tomar uma determinada ação para evitar ou solucionar o problema. É possível, por
exemplo, reiniciar um serviço crítico de um servidor que não pode ficar fora do ar
por muito tempo sem que os usuários notem a sua queda.
O requisito básico para a implementação desses tipos de projetos é instalar ou ha-
bilitar no servidor ou no dispositivo de rede a ser monitorado um serviço chamado
SNMP (Simple Network Management Protocol), isto é, um serviço que possibilite o ge-
renciamento e a administração remota dos servidores críticos ou dos dispositivos de
rede através de ferramentas de gerenciamento de infra-estrutura. Esse serviço
SNMP geralmente vem incluído nos pacotes de instalação dos sistemas operacionais
existentes e está presente nos dispositivos de rede. É necessário configurar o SNMP
para o devido funcionamento.
Por fornecerem recursos muito específicos e de tecnologia de ponta, as ferramen-
tas de gerenciamento de infra-estrutura não vêm “embutidas” (built-in) nos sistemas
operacionais. Elas devem ser adquiridas à parte, com seus respectivos fabricantes.
Entre os provedores desse tipo de ferramentas destacam-se a Cisco, IBM, Microsoft
HP, Novell, Computer Associates, BMC e Altiris. Existem também ferramentas si-
milares desenvolvidas na plataforma Linux.

CAPÍTULO 12 395
Entre as várias soluções fornecidas por este tipo de projeto, temos por exemplo:
Inventário de hardware e software

Sistemas de restauração de informações (backups de servidores em geral: ban-
co de dados, e-mails, arquivos)
Distribuição ou instalação de software via rede
Sistemas de Help Desk
Sistemas de controle remoto para administração de servidores e estações
Sistemas de monitoramento de servidores em geral
Sistemas de segurança e antivírus
Sistemas de análise de performance em geral (servidores e links de redes)
Projetos de infra-estrutura normalmente são de grande porte e podem ser dividi-

dos em quatro fases:
1. Escolha e aquisição do produto

2. Escolha e contratação de uma organização de consultoria
3. Implantação (inclusive com transferência de tecnologia ou know-how)
4. Suporte pós-implantação
Entre os principais benefícios deste tipo de projeto podemos citar:
Garante a disponibilidade de aplicações críticas para o sucesso do seu negócio,

ajudando-o a atingir o máximo de disponibilidade.
Faz o monitoramento dos recursos para garantir a performance ideal de aplica-
ções críticas, tais como: sistema operacional, banco de dados, rede e seus dis-
positivos, tais como hubs, routers, switches e gateways.
Gerencia aplicações críticas como ERPs (SAP, Oracle Financial, BAAN etc.),
correios eletrônicos, middleware, aplicações Web etc.
Gerencia os ciclos de vida das aplicações críticas dos negócios, simplificando o
processo de instalação e upgrades de software em ambientes heterogêneos e
dispersos.
Permite planejamento prévio de mudanças no ambiente, através de um inven-
tário atualizado dos bens (ativos) de hardware e software. Essa ferramenta ajuda
no controle de licenças de software, evitando exposições por uso de softwares
piratas.
Faz o controle de mudanças remotamente, evitando que administradores do
sistema tenham de deslocar-se fisicamente.
Possibilita auxiliar efetivamente o usuário final, sem a necessidade de desloca-
mentos físicos por parte dos administradores e do pessoal de suporte técnico.

Permite um crescimento consistente dos bens (ativos) de TI, assegurando que

novos usuários tenham acesso a todos os recursos cruciais ao desenvolvimento
de suas atividades.
Torna possível a automação total de processos batch em plataformas heterogê-
neas, bem como a tomada de ações de gerenciamento proativas nas aplicações
on-line.
Permite que você faça a implementação rápida e segura de uma política de segu-
rança consistente e corporativa, cobrindo as áreas de sistemas legados, sistemas
cliente-servidor e aplicações e-business.
Faz o gerenciamento centralizado das políticas de segurança e tomadas de ações
proativas no caso de possíveis ataques.
Possibilita a otimização dos processos de manutenção das políticas de seguran-
ça, aumentando a eficiência e o grau de satisfação do usuário final, bem como
reduzindo custos associados a essa operação.
Permite soluções de backup/restauração para dezenas de plataformas, através
de uma administração centralizada e com suporte a vários fornecedores de
hardware para armazenamento.
Permite antecipar e prever problemas na rede.
Fornece um mapeamento automático de toda a rede e seus dispositivos (conhe-
cido como discovery da rede), permitindo o rápido acesso, administração remo-
ta a partir de uma única console e visualização gráfica de todos os pontos da rede
corporativa, seja ela local (LAN), metropolitana (MAN) ou mundial (WAN).
Enfim, inúmeros são os benefícios agregados que as organizações podem obter

através da realização de projetos de gerenciamento de infra-estrutura.
Ressalto a necessidade de contratação de consultorias especializadas para a imple-
mentação desses projetos, mesmo se a organização contratante já possuir recursos
internos com conhecimentos nas ferramentas. As organizações consultoras normal-
mente têm um canal direto com o fabricante das ferramentas de gerenciamento de
infra-estrutura, facilitando o suporte e a implementação desse tipo de projeto, além
de pessoal altamente qualificado, experiente e certificado.
A maioria dos fabricantes de ferramentas de gerenciamento de infra-estrutura
permite que você faça um test drive, através de disponibilização de downloads de ver-
sões de avaliação em seus Web sites. Você poderá também fazer downloads de ma-
nuais completos de algumas das ferramentas em arquivos .pdf; além de obter infor-
mações complementares e mais detalhes técnicos sobre os produtos e suas arquitetu-
ras. Você tem um mundo de informação sobre as ferramentas de gerenciamento de
infra-estrutura esperando e, para acessá-lo, você precisará de apenas alguns cliques
do mouse e de uma conexão banda larga com a Internet.

CAPÍTULO 12 397
A seguir está uma relação dos respectivos URLs. Não deixe de visitá-los e princi-
palmente de fazer downloads dos produtos e arquivos afins.
Só uma ressalva final em relação às ferramentas: faça o “test drive” num ambiente
de laboratório; dessa forma, você poderá ficar à vontade. Somente através da realiza-
ção de projetos de gerenciamento de infra-estrutura é possível adotar essas ferra-
mentas em ambientes de produção.
http://www.cisco.com/en/US/netsol/ns110/ns106/net_solution_home.html
http://www-3.ibm.com/e-business/br/infrastructure/software/tivoli/index.shtml/
http://www.microsoft.com/brasil/gerenciamento/default.asp
http://www.hp.com/products1/softwareproducts/highavailability/index.html/
http://www.novell.com/products/zenworks/sdsuite/
http://www.bmc.com/products/
http://www3.ca.com/solutions/solution.asp?id=315/
http://www.altiris.com/
PROJETOS DE SOFTWARE
Os projetos de software estão relacionados a todo o ambiente de desenvolvimento
de aplicativos, que vai desde a modelagem de dados, passando pela administração de
dados até a organização por equipes internas de desenvolvimento. Os exemplos de
projetos de software aqui citados serão:
Administração de dados
Integração e customização de ferramentas CASE
Migração entre ferramentas CASE
Modernização de sistemas legados
Administração de dados
Para enfrentar o desafio da competitividade cada vez mais acirrada e as constan-
tes mudanças no mercado, as organizações estão buscando mecanismos eficazes
para a tomada de decisão, tais como Data Warehouse e Business Intelligence. Tais
mecanismos estão fundamentados em informações, que necessitam ser confiáveis
e de fácil acesso.
O sucesso de tais projetos está intimamente relacionado à qualidade dos dados ar-
mazenados, tornando a confiabilidade, integridade, integração, conceituação, docu-
mentação, disponibilidade, acessibilidade e segurança fatores cruciais na obtenção
dessa qualidade.
Através de seus principais instrumentos de trabalho (dicionário de dados, meto-
dologias e padrões), a Administração de Dados garante os instrumentos necessários
para obtenção de informações de qualidade, como o mapeamento das estruturas de
dados, identificando sua localização e conceito, bem como garantindo a devida reuti-
lização, integração e integridade.

Diante dessas premissas, projetos dessa área ajudam a organização a administrar

os dados em todas as fases de seu ciclo de vida, contribuindo decisivamente para o su-
cesso de seus projetos e para a tomada de decisões.
Por ser bem extensa a Administração de Dados, normalmente se modularizam es-
ses serviços, conforme a seguir:
Estruturação da Área de AD
Diagnóstico da Área de AD
Otimização dos Processos de Gestão de Dados
Implantação de Metodologias e Padrões
Auditoria de Modelos de Dados
Implantação de Ferramentas de Apoio
Construção do Modelo Corporativo de Referência
Estruturação do Dicionário de Dados
Outsourcing
Estruturação da área de AD
Uma boa administração de dados permite o gerenciamento dos dados como um bem
patrimonial da organização.
Todos os procedimentos, metodologias e padrões relacionados ao ambiente de
dados são definidos e estruturados, de forma a transferir know-how aos administra-
dores de dados, garantindo que toda a organização possua uma visão integrada do seu
acervo de dados e esteja apta a administrá-los de maneira organizada, efetiva e pro-
dutiva.
Diagnóstico da área de AD
Este serviço analisa procedimentos, metodologias, padrões e nível de dicionarização
dos modelos de dados e elabora um diagnóstico com propostas de solução dos pro-
blemas identificados para as organizações que já possuem a administração de dados e
querem avaliar a sua atuação de forma a otimizar os resultados.
Otimização dos processos de gestão de dados

A partir do diagnóstico da área de AD, formula-se um plano de otimização que dire-
cionará a evolução dos Processos de Gestão de Dados.
Implantação de metodologias e padrões

É importante que a organização possua metodologias e padrões próprios voltados
para suportar as atividades do gerenciamento de dados. São metodologias funda-
mentadas nas principais técnicas de mercado que garantem uma integração perfeita
entre técnica e prática.

CAPÍTULO 12 399
Estruturação do dicionário de dados

O dicionário de dados é uma das principais ferramentas para o gerenciamento dos
dados em uma organização.
Com base em engenharia reversa, armazenam-se os modelos de dados, as estrutu-
ras de dados, seus relacionamentos, os conceitos e toda a documentação adicional
necessária para garantir facilidade na localização e manipulação dos dados.
Construção do modelo corporativo de referência

A construção e documentação do Modelo de Dados Corporativo de Referência é
uma visão integrada das estruturas de informação estruturada de forma a torná-la
acessível para toda a organização.
Implantação de ferramentas de apoio

As ferramentas CASE utilizadas em conjunto com a administração de dados garan-
tem um ambiente de gerenciamento automatizado, produtivo e eficaz.
Neste serviço, cuida-se da devida implantação das ferramentas CASE para mode-
lagem de dados, para validação de padrões de nomenclatura e para a análise de con-
sistência das estruturas de dados.
Auditoria de modelos de dados

A aplicação correta das técnicas de modelagem de dados é um dos fundamentos para
a obtenção de dados com qualidade. A auditoria de modelos garante a qualidade do
modelo de dados em termos técnicos, indicando os pontos de melhoria e contribuin-
do para o aumento da qualidade dos dados.
Outsourcing
Este serviço aloca profissionais de organizações especializadas em modelagem de da-
dos para atuação como Administradores de Dados e/ou Modeladores de Dados,
permitindo, além da execução das funções de AD, a transferência de know-how para
a equipe de desenvolvimento.
Integração e customização de ferramentas CASE

Para entender o objetivo deste tipo de projeto, primeiramente devemos verificar em
qual cenário ele se insere e quais departamentos estão envolvidos.
A customização é solicitada e feita no departamento de Tecnologia da Informação
das organizações, junto com as equipes de desenvolvimento, AD e DBA.
Este tipo de projeto requer muitas customizações através de desenvolvimento de
sistemas ou componentes utilizando API (Application Program Interface) e linguagens
de última geração, já que sua missão é fornecer soluções práticas para problemas téc-
nicos de integração de ferramentas CASE (Computer Aided Sotfware Engineering) e mi-
gração de metadados.

Essas customizações normalmente são desenvolvidas por organizações com gran-

de know-how no mercado de modelagem de dados, as quais são líderes na comercia-
lização de ferramentas CASE, na realização de projetos de administração de dados e
nos treinamentos corporativos.
Normalmente, nos processos de desenvolvimento e administração da TI encon-
tram-se dificuldades em algumas tarefas que não são atendidas pelas tecnologias
atuais. Esses gaps tecnológicos causam retrabalho, falhas, gargalos e um custo alto.
E são nessas “fendas” que os projetos de customização e integração de ferramentas
CASE podem ser fomentados, realizados e trazem muitos benefícios para as orga-
nizações.
Portanto, o objetivo primário é ajudar as equipes de desenvolvimento dos clientes
a ter um ambiente de trabalho mais produtivo e eficiente, provendo o ferramental
complementar para administração da TI.
Isso abrange dados, bancos de dados, processos de qualidade do desenvolvimento
de sistemas, processos de análise, implementações e documentação de sistemas.
Uma variante, em particular, desse objetivo é a migração de metadados entre fer-
ramentas CASE, que será abordada no próximo tópico.
Migração entre ferramentas CASE de modelagem de dados

As organizações que estão em processo de mudança de tecnologia e desejam adotar
alguma ferramenta CASE de modelagem de dados do mercado têm a necessidade de
preservar o legado documentado dos sistemas existentes, realizar a manutenção des-
ses sistemas e unificar a plataforma de desenvolvimento de modelos de dados.
Para atender a essas necessidades, é preciso desenvolver aplicações de migração
entre ferramentas CASE ou utilizar ferramentas de mercado que possam fazer parte
ou toda a tarefa.
Essas aplicações de migração acessam os metadados armazenados em arquivos ou
repositórios de uma ferramenta CASE e transferem para outra ferramenta CASE. É
claro que alguns ajustes são necessários devido às diferenças de plataformas e tecno-
logias entre as próprias ferramentas CASE, mas esses ajustes também podem fazer
parte do projeto.
Projetos de migração entre ferramentas CASE possibilitam que as organizações
adotem novas tecnologias, preservando informações e todo investimento já feito, e
compatibilizando as tecnologias com rapidez e segurança.
Modernização de sistemas legados

Em uma economia dirigida a ambientes distribuídos e à Internet, você pode desco-
brir que seus sistemas legados, tanto os de mainframe quanto os de plataforma baixa,
são uma barreira aos seus esforços de obter vantagem no gigantesco retorno hoje ofe-
recido pelas iniciativas modernas de sistemas distribuídos e de e-business.

CAPÍTULO 12 401
Anos de modificações resultaram em sistemas com arquiteturas inadequadas ao

ambiente distribuído, elevando os custos de sua manutenção. Além disso, a carência
de recursos habilitados e as pressões externas por mudanças economicamente viá-
veis podem estar indicando a necessidade de modernizar seus sistemas legados.
Os pré-requisitos básicos para essa modernização de sistemas são:
Compreensão/documentação (relatórios/diagramas em html).

Componentização de “serviços” (regras de negócio e “slices”).
Transformação de código e dados.
Interface: de textual para GUI.
Lógica: de uma linguagem para outra mais adequada.
Acesso a dados: de um esquema de acesso para outro.
Dados: de hierárquicos e seqüencial para relacional.
Existem soluções completas para automatizar, simplificar e agilizar a transforma-

ção de sistemas legados para plataformas modernas de tecnologia. Essas soluções são
implementadas por empresas de consultorias especializadas no assunto, as quais po-
dem ser contratadas no Brasil.
Os benefícios para este tipo de projeto são:
Minimizar riscos: utilizando as regras de negócio de seu sistema atual, as transa-

ções Web estarão lidando de uma forma consistente com processos de negócio
comprovados.
Reduzir tempo de implementação.
Reduzir prazos para estimativas, análise e conversão.
Diminuir custos de operação: mudando sistemas para novas plataformas, ob-
tém-se a oportunidade de economizar através do ganho com eficiência opera-
cional.
Aumentar satisfação do usuário do negócio: transformando uma aplicação de
“tela verde” para Java, C++, Visual Basic ou HTML, tem-se mais opções de de-
senho de interface para facilitar o uso da aplicação.
Os resultados (produto) deste esforço incluirão:

Sistema transformado
Documentação de sistema
Desenho da arquitetura do sistema
Componentes integrados para teste
Relatório de teste unitário e integrado
Documentação do Projeto

Resumo do Processo
O processo de Transformação de Legado pode envolver as seguintes fases:
Inventário e Análise
Preparação para Transformação
Transformação de Lógica de Negócio
Teste
Produção
Customização do código transformado
Durante a fase de Inventário e Análise, é feito um inventário de todos os objetos

do sistema, são coletadas métricas, e o sistema é documentado. Conceituar os siste-
mas como parte da análise leva à definição da arquitetura do software e fornece uma
base para a subdivisão lógica do sistema para as atividades seguintes.
A fase de Preparação para Transformação envolve o desenho físico da arquitetura
alvo, definindo padrões e subseqüentemente orientando a transformação dos com-
ponentes selecionados para a arquitetura alvo.
Uma vez transformados, os componentes serão testados para determinar caracte-
rísticas específicas de ambiente. Isso permite que processos de melhoria sejam iden-
tificados e incorporados no restante do projeto a fim de aumentar sua eficiência.
Com toda a estrutura da aplicação montada, cada módulo será então transforma-
do da linguagem legada para a plataforma alvo usando transformação automatizada,
suplementada pela codificação customizada conforme a necessidade.
O objetivo é a alta qualidade com código de fácil manutenção, equivalente ao siste-
ma existente, e que servirá como base sólida para futuras modificações e melhorias no
sistema. Os padrões do cliente para executar a fase final de testes devem ser seguidos.
CONCLUSÃO
Dezenas, ou quiçá centenas, são os tipos possíveis de projetos de tecnologia da infor-
mação e correlacionados que podem ser fomentados e executados nas organizações.
É essencial que todos esses projetos estejam sempre alinhados com os objetivos es-
tratégicos de negócios da organização e com o Plano Diretor de Informática.
Vimos como os projetos estratégicos, de infra-estrutura e de desenvolvimento de
software são importantes para as organizações, pois afetam diretamente a “alma do
negócio”. Reserve sempre verbas anuais generosas para a execução de tais projetos. O
retorno do investimento é garantido e a concorrência precisa suar um pouco mais
para tentar acompanhar a sua organização!
Considere sempre a possibilidade de contratação de consultorias especializadas
para implementar esses projetos. No Brasil existem diversas organizações especiali-
zadas na execução dos projetos aqui apresentados. E, como garantia do cumprimen-
to dos requisitos, do escopo, dos prazos, dos custos, da qualidade e uma efetiva utili-

CAPÍTULO 12 403
zação dos recursos humanos, exija em contrato a utilização de uma metodologia de ge-
renciamento de projetos, preferencialmente, seguindo as práticas do PMI, que já de-
monstraram ser mundialmente eficazes.
Mas lembre-se de um aspecto muito importante que faz a diferença para toda essa
engrenagem funcionar: ter somente uma metodologia de gerenciamento de projetos que ga-
ranta o cumprimento do escopo, dentro do prazo estimado, sem alterações no orçamento e com a
qualidade esperada (ou superada) não é o suficiente. É preciso, acima de tudo, muito talento e
comprometimento com os resultados de todos os envolvidos no projeto.
Espero que você tenha encontrado neste capítulo informações relevantes e sufi-
cientes para ajudá-lo a vender o peixe na sua organização.

Um toque especial
do Autor
Tom Peters, um desses gurus da administração moderna, disse há alguns anos que
“agora vivemos em um mundo de projetos”.
Na verdade, desde que o mundo é mundo existem os projetos.
Aliás, o próprio mundo foi o primeiro grande projeto a ser construído por Deus.
Podemos considerar esse fato como sendo a Gênesis dos Projetos.
Como todo projeto tem um prazo e etapas, Deus administrou o cronograma da
construção do mundo em fases distintas: em sete dias, nos quais seriam criados pro-
dutos únicos.
No primeiro dia, Deus criou a luz. No segundo dia, criou o céu. No terceiro dia, criou a
terra, os mares, a relva e as árvores frutíferas. No quarto dia, Deus criou as estrelas, o Sol e
a Lua; e os colocou no céu para diferenciar o dia da noite. No quinto dia, criou os peixes e os
animais terrestres. No sexto dia, Deus criou o homem e a mulher. No sétimo dia, Deus des-
cansou.
Nessa empreitada, Deus atuou ao mesmo tempo como patrocinador, gerente,
Criador, e como “Quality Assurance” do projeto, pois tudo o que fazia, considerava
bom e, portanto, passava pela Sua aprovação final.
Deus concedeu ao homem, produto gerado no sexto dia, alguns dons maravilho-
sos, como a procriação, habilidades de comunicação, inteligência e criatividade para
produzir ferramentas. A partir dessas habilidades, o homem foi construindo aos pou-
cos a sua história e o mundo no qual vivemos hoje.

Saber qual é o projeto de nossas vidas, ou seja, compreender por que fomos con-
cebidos pelo Grande Arquiteto do Universo e como devemos gerenciar o tempo que Ele
nos concede aqui neste mundo é a chave do sucesso e da felicidade de cada um.
Devemos começar utilizando o nosso livre arbítrio somente para o bem, pois te-
mos pela frente o maior dos desafios da humanidade: tomar conta do mundo através
de ações projetizadas, com a dignidade e o compromisso de (re)criar um ambiente
mais justo, saudável e pacífico de se viver. E outro aspecto importante, descrito no
livro Jesus, o maior executivo que já existiu, de Charles C. Manz, da Campus/Elsevier:
“Compaixão, perdão e sabedoria encontram seu espaço no mundo contemporâneo dos negócios –
complexo e dinâmico –, e podem construir parte essencial do envolvimento em carreiras e orga-
nizações que gerem maior significado, satisfação e sucesso.”
Juntos podemos trabalhar em equipe com o objetivo de devolver para Deus o
mundo assim como Ele planejou nas Gênesis. Dessa forma, estaremos devolvendo
para nós mesmos um novo mundo, onde possamos enxergar o próximo, sentir o
amor e a vontade de ajudar e, acima de tudo, cultivar o respeito e a fé na onisciência,
onipresença e onipotência de Deus e na Sua Palavra. Agora vivemos em um mundo onde
todos nós fazemos parte do mesmo projeto!
Marconi Fábio Vieira

PMP, MCT, MCP, CUE, CUA,
CACP Storage Specialist e CNS

APÊN D ICE A
Bibliografia sugerida
Aqui você encontrará uma extensa referência bibliográfica para ajudar nas pesquisas
e no aprofundamento dos assuntos.
Esta lista foi elaborada e gentilmente cedida pelo autor do Prefácio deste livro.
A lista está dividida nos seguintes tópicos: gerais básicos, gerais avançados, PMP
Exam – PMI Package, PMP Exam – Testes, casos reais, recursos humanos, tempo,
riscos, contratos e suprimentos, organizações, qualidade, comunicações, Valor
Agregado, Corrente Crítica e os livros de Ricardo Viana Vargas.
Gerais básicos
Livros básicos e introdutórios sobre gerenciamento de projetos:
1. A Guide to the Project Management Body of Knowledge. Newton Square: Project Management
Institute, 2000.
2. ADAMS, J. et al Principles of Project Management. Newton Square: Project Management
Institute, 1997.
3. DELUCIA, Al & DELUCIA, J. Recipes for Project Success. Newton Square: Project Manage-
ment Institute, 1999.
4. EISNER, Howard. Essentials of Project and Systems Engineering Management. Nova York: John
Wiley & Sons, 1996.
5. FRAME, J. D. New Project Management, The. Nova York: Jossey-Bass Inc, 1994
6. HAYNES, M. E. Project Management: A Pratical Guide for Success – Revised Edition. Crisp Pu-
blications, 1999.
7. KERZER, Harold. Project Management: A systems approach to planning scheduling and control-
ling. 6a ed. Nova York: Van Nostrand Reinhold, 1998.

8. KLIEM, Ralph L. & LUDIN, Irwin S. Tools and Tips for Today’s Project Manager. Newtown
Square: Project Management Institute, 1999.
9. LEWIS, James P. Fundamentals of Project Management. Nova York: Amacom, 1997.
10. LEWIS, James P. Project Planning, Scheduling & Control. Chicago: Irwin Professional Publis-
hing, 1995.
11. LOCK, Dennis. Project Management. Nova York: John Wiley & Sons, 1996.
12. Memory Jogger II, The. Lawrence: Goal/QPC, 1994.
13. Project Management Experience and Knowledge Self-Assessment Manual. Newtown Square: Pro-
ject Management Institute, 2000.
14. Project Management Memory Jogger. Lawrence: Goal/QPC: 1997.
15. SHTUB, Avraham & BARD, Jonathan F., GLOBERSON, Shlomo. Project Management –
Engineering, Technology and Implementation. Nova Jersey: Prentice Hall, 1994.
16. The Future of Project Management. Newtown Square: Project Management Institute,
1999.
17. The PMI Project Management Fact Book. Newtown Square: Project Management Institute,
1999.
18. VALERIANO, Gerência em Projetos: Pesquisa, Desenvolvimento e Engenharia. São Paulo: Mak-
ron Books, 1998.
19. WEISS, J. & WYSOCKI, R. K. (1992). 5-Phase Project Management: A practical Planning
and Implementation Guide. Perseus Books Publising, 1992.
20. WIDEMAN, R. Max. A Framework for Project and Program Management Integration. Upper
Darby: Project Management Institute, 1991.
21. WISNER, Joel D. and FAWCETT, Stanley E. Linking Firm Strategy to Operating Decision
Through Performance Measurement. Production and Inventory Management Journal – Third
Quarter, 1991.
22. WYSOCKI, R. K., BECK, R. & CRANE, D. B. Effective Project Management: How to
Plan, Manage, and Deliver a Project on Time and Within Budget. Nova York: John Wiley,
2000.
Gerais avançados
Livros que devem ser lidos em um segundo momento, após absorvidos os conceitos básicos intro-
dutórios.
23. BODDIE, John e METZGER, Philip W. Managing a Programming Project. London: Prentice
Hall, 1997.
24. CLELAND, David I. Project Management: Strategic Design and Implementation. Nova York:
McGraw-Hill, 1999.
25. DEVAUX, S. A. Total Project Control. Nova York: John Wiley and Sons, 1999.
26. DOBSON, Michael S. The Juggler’s Guide to Managing Multiple Projects. Filadélfia: Project
Management Institute, 1999.
27. MEREDITH, Jack R. & MANTEL JR., Samuel J. Project Management: A Managerial Ap-
proach. Nova York: John Wiley and Sons, 1995.
28. PINTO, J. K. & TRAILER, J. W. Essentials of Project Control. Newton Square: Project Ma-
nagement Institute, 1999.
29. THIRY, Michael. Value Management Practice. Newton Square: Project Management Institu-
te, 1997.
30. THOMSETT, M. C. The Little Black Book of Project Management. Nova York: Amacom,
1990.

BIBLIOGRAFIA SUGERIDA
APÊNDICE A 409
PMP Exam – PMI Package

Livros sugeridos oficialmente pelo PMI para os interessados em prestar o exame PMP.
31. A Guide to the Project Management Body of Knowledge. Newton Square: Project Management
Institute, 2000. (1996 até fim de 2001)
32. ADAMS, J., et al Principles of Project Management. Newton Square: Project Management
Institute, 1997.
33. BRAKE, T., WALKER, D. & WALKER, T. Doing Business Internationally: The Guide to
Cross-Cultural Success. Nova York: McGraw-Hill Professional Book Group, 1995.
34. CLELAND, D., BURSIC, K. M., PUERZER, R. & VLASAK, Y. Project Management Case-
book, Upper Darby: Project Management Institute, 1997.
35. FLEMING, Q. W. e KOPPELMAN, J. M. Earned Value Project Management, 2a ed. Newton
36. FRAME, J. D. The New Project Management. Jossey-Bass Inc, 1994
37. KERZER, Harold. Project Management: A systems approach to planning scheduling and control-
a
ling, 6 ed. Nova York: Van Nostrand Reinhold, 1998.
38. MEREDITH, Jack R. & MANTEL JR., Samuel J. Project Management: A Managerial Ap-
proach. Nova York: John Wiley and Sons, 1995.
39. Project Management Experience and Knowledge Self-Assessment Manual. Newtown Square: Pro-
40. ROSEN, R., DIGH, P. & PHILLIPS, C. Global Literacies: Lessons on Business Leadership and
National Cultures. Simon, 2000.
41. VERMA, V. Organizing Projects for Success, vol. 1. Upper Darby: Project Management Insti-
tute, 1995.
42. VERMA, Vijay K. Human Resource Skills for the Project Manager, vol. 2. Upper Darby: Pro-
43. WIDEMAN, R. Max. Project & Program Risk Management: A Guide to Managing Project Risks &
Opportunities. Upper Darby: Project Management Institute, 1992.
44. WYSOCKI, R. K., BECK, R. & CRANE, D. B. Effective Project Management: How to
Plan, Manage, and Deliver a Project on Time and Within Budget. Nova York: John Wiley,
2000.
EXAME PMP – Testes

Livros com questões sugeridas para os interessados em prestar o exame PMP:
45. MULCAHY, R. PMP Exam Prep. Nova York: The Twiggs Company, 1999.
46. WARD, J. L. & LEVIN G. PMP Chalenge!, Washington: ESI International, 1999.
47. WARD, J. L., PMP Exam: Practice Test and Study Guide. Washington: ESI International,
2000.
Casos reais
Livros que destacam casos e aplicações do gerenciamento de projetos no mundo:
48. CLELAND, David, BURSIC, Karen M., PUERZER, Richard & VLASAK, Yaroslav. Pro-
ject Management Casebook, Upper Darby: Project Management Institute, 1997.
49. _________. Project management Casebook: Instructor’s Manual. Upper Darby: Project Mana-
gement Institute, 1997.
50. KERZNER, Harold. In Search of Excellence in Project Management: Successful Practices in High
Performance Organizations. Nova York: Van Nostrand Reinhold, 1998.

Recursos humanos
51. ADAMS, John R. & CAMPBELL, Bryan W. Roles and Responsibilities of The Project Manager.
Upper Darby: Project Management Institute, 1982.
52. DINSMORE, Paul C., MARTIN, Martin C. & HUETTEL, Gary T. The Project Manager’s
Work Environment: Coping with Time and Stress. Upper Darby: Project Management Institute,
1985.
53. LOVE, N. & LOVE, J. B. The Project Sponsor Guide. Newton Square: Project Management
Institute, 2000.
54. PAGNOCELLI, Dernizo & VASCONCELOS FILHO, Paulo. Sucesso Empresarial Planejado.
Rio de Janeiro: Qualitymark Ed., 1992.
55. PINTO, Jeffrey K. & TRAILER, Jeffrey W. Leadership Skills for Project Managers. Newtown
56. Team Memory Jogger, The. Lawrence: Goal/QPC and Oriel Incorporated: 1995.
57. The Creative Tools Memory Jogger. Lawrence: Goal/QPC: 1998.
58. VASCONCELLOS, Paulo Filho & PAGNOCELLI, Dernizo. Sucesso Empresarial Planejado.
Rio de Janeiro: Qualitymark Editora, 1992.
59. VERMA, Vijay K. Human Resource Skills for the Project Manager, vol. 2. Upper Darby: Pro-
60. ____. Managing the Project Team, vol. 3. Upper Darby: Project Management Institute,
1995.
61. ____. Organizing Projects for Success, vol. 1. Upper Darby: Project Management Institute,
1995.
Tempo
a
62. BELANGER, T. C. How to Plan Any Project: A Guide for Teams (and Individuals), 2 ed. Ster-
ling: The Sterling Planning Group, 1995.
63. KELLEY, Robert M. Planning Techniques (Basic and Advanced): A Graphic, Self-Checking Plan-
ning Method. Kettering: Kelley Communications Development, 1988.
64. MULVANEY, J. Analysis Bar Charting: a simplified critical path analysis technique. Bethesda:
Management Planning and Control Systems, 1969.
th
65. MURMIS, Gustavo Marcelo. “S” Curves for Monitoring Project Progress. Long Beach: 29 Annual
Project Management Institute Seminars & Symposium, 1998.
66. SANDERS, Norman. Stop Wasting Time: Computer-Aided Planning and Control. Londres:
Prentice Hall, 1991.
Riscos
67. MARION, Ed. Using Monte Carlo Analysis for Project Tracking. Long Beach: 29th Annual Pro-
ject Management Institute Seminars & Symposium, 1998.
68. SCHUYLER, John R. Decision Analysis in Projects: Learn to Make Faster, More Confident Deci-
sions. Upper Darby: Project Management Institute, 1996.
69. WIDEMAN, R. Max. Project & Program Risk Management: A Guide to Managing Project Risks &
Opportunities. Upper Darby: Project Management Institute, 1992.
Contratos e suprimentos
70. CAVENDISH, Penny & MARTIN, Martin D. Negotiating & Contracting for Project Manage-
ment. Upper Darby: Project Management Institute, 1982.
71. FLEMING, Q. W. & FLEMING Q. J. Subcontract Planning and Organization. Chicago: Pro-
bus, 1993.

BIBLIOGRAFIA SUGERIDA
APÊNDICE A 411
72. HUSTON, C. L. Management of Project Procurement. Nova York: McGraw-Hill, 1996.
73. MARTIN, Martin D., TEAGARDEN, C. Claude & LAMBRETH, Charles F. Contract
Administration for The Project Manager. Upper Darby: Project Management Institute, 1983.
Organizações
74. BLOCK, T. R. & FRAME, J. D. The Project Office. Menlo Park: Crisp Publications, 1998.
75. BRAKE, T., WALKER, D. & WALKER, T. Doing Business Internationally: The Guide to
Cross-Cultural Success. Nova York: McGraw-Hill Professional Book Group, 1995.
76. CABLE, Dwayne & ADAMS, John R. Organizing for Project Management. Upper Darby:
Project Management Institute, 1982.
77. GALBRAITH, Jay R. Designing Organizations: An Executive Briefing on Strategy, Structure and
Process. San Francisco: Jossey-Bass Publishers, 1995.
78. GALBRAITH, Jay R. Designing Organizations: An Executive Briefing on Strategy, Structure and
Process. San Francisco: Jossey-Bass Publishers, 1995.
79. MINTZBERG, Henry. Criando Organizações Eficazes: Estruturas em Cinco Configurações. São
Paulo: Atlas: 1995.
80. ROSEN, R., DIGH, P. & PHILLIPS, C. Global Literacies: Lessons on Business Leadership and
National Cultures. Simon, 2000
81. VERMA, V. Organizing Projects for Success, vol. 1. Upper Darby: Project Management Insti-
tute, 1995.
82. WESTNEY, Richard E. Strategic Project Planner. Nova York: Amoco Corporation and
Westney Consultants International, 1995.
Qualidade
83. DARNALL, Russel W. The World Greatest Project: One Project Team on the Path to Quality.
Newton Square: Project Management Institute: 1996.
84. IRELAND, Lewis R. Quality Management for Projects and Programs. Upper Darby: Project
Management Institute, 1991.
85. SHUSTER, H. D. Teaming for Quality – The Right Way for The Right Reasons. Newton
Comunicações
86. FLAPPER, Simme Douwe P., FORTUIN Leonard and STOOP, Paul P. M. Towards Consistent
Performance Management Systems. International Journal of Operations & productions Manage-
ment, vol. 16. n. 7, University Press, 1996.
87. MAYER, Margery. The Virtual Edge: Embracing Technology for Distributed Project Team Success.
Newtown Square: Project Management Institute, 1998.
88. TERREL, Michael S., BROCK, Anthony W., WISE, Jonatham R. Evaluating Project Perfor-
mance Tools – A Case Study. Long Beach: 29th Annual Project Management Institute Semi-
nars & Symposium, 1998.
89. The PMI Book of Project Management Forms. Upper Darby: Project Management Institute,
1997.
Valor agregado
th
90. BEATTY, John P. Earned Value for Professional Private Organizations. Long Beach: 29 Annual
Project Management Institute Seminars & Symposium, 1998.
91. BRANDON JR, D. M. (1998). Implementing Earned Value Easily and Effectively. Project Ma-
nagement Journal, Filadélfia, vol. 29/2..

92. CHRISTENSEN, D. S. (1994). A Review of Cost/Schedule Control Systems Criteria Lite-

rature in Project Management Journal, vol. 25/3. Filadélfia.
93. CHRISTENSEN, D. S. (1998) The Cost and Benefits of The Earned Value Management Process.
Acquisition Review Quartely.
94. CLELAND, D. (1999). Project Management: Strategic Design and Implementation. Nova York:
McGraw-Hill.
95. FLEMING, Q. W. e KOPPELMAN, J. M. (1999a) Earned Value Project Management, 2a ed.
Newton Square: Project Management Institute.
96. FLEMING, Q. W. e KOPPELMAN, J. M. (1999b) Earned Value Body of Knowledge. Phila-
delphia: 30th Annual Project Management Institute 1999 Seminars & Symposium.
97. FOGARTY, Richard. Payment by Earned Value. The College of Performance Management
Journal “The Measurable News”, 1999.
98. GREEN, D. (1998). Project Control Through Earned Value. Long Beach: 29th Annual Project
Management Institute Seminars & Symposium.
99. STRATTON, Ray W. Improving SPI and CPI Calculations on LOE Heavy Programs. Philadelp-
hia: 30th Annual Project Management Institute Seminars & Symposium, 1999.
Corrente crítica
100. GOLDRATT, Eliyahu M. Critical Chain. Great Barrington: The North River Press, 1997.
101. LEACH, Lawrence. Critical Chain Project Management. Long Beach: 29th Annual Project
Management Institute Seminars & Symposium, 1998.
Livros de Ricardo Viana Vargas

102. VARGAS, Ricardo V. Gerenciamento de Projetos: Estratégia, Planejamento e Controle com o MS
Project 98. Rio de Janeiro: Brasport, 1998.
103. ____. Gerenciamento de Projetos: Estabelecendo Diferenciais Competitivos. 2a ed. Rio de Janeiro:
Brasport, 2000.
104. ____. Microsoft Project 2000: Transformando Projetos em Resultados de Negócios. Rio de Janei-
ro: Brasport, 2000.
105. ____. Análise de Valor Agregado em Projetos. Rio de Janeiro: Brasport, 2002.
106. ____. Microsoft Project 2002 Professional e Server. Rio de Janeiro: Brasport, 2002.

APÊN D ICE B
Informações complementares
Há uma série de arquivos disponibilizados no CD, no diretório “Apêndice”. São in-

formações complementares e muito úteis. Esses arquivos foram gentilmente cedi-
dos por Ricardo Viana Vargas.
A lista se divide nos seguintes tópicos:
Gerais
PMI
Metodologia PMBOK Guide do PMI
Certificações PMI
Reports Regionais sobre Gerenciamento de Projetos
Palestras e Artigos sobre Gerenciamento de Projetos
Microsoft Project e Enterprise Project Management
Outros Arquivos

GERAIS
Tamanho Nome
Nome Descrição do arquivo Formato Idioma Arquivo
Bibliografia Lista a bibliografia de 178KB Adobe PDF Português Bibliografia.pdf
Sugerida gerenciamento aproximadamente
de projetos 40 segundos a 56K
Bibliografia Lista a bibliografia de 117KB Microsoft Português Bibliografia.lit
Sugerida gerenciamento aproximadamente Reader
de projetos 25 segundos a 56K
Sites sobre Listagem dos sites mais 90KB Adobe PDF Português Sites.pdf
Gerenciamento acessados sobre aproximadamente
de Projetos gerenciamento de 20 segundos a 56K
projetos e ferramentas
Sites sobre Listagem dos sites mais 110KB Microsoft Português Sites.lit
Gerenciamento acessados sobre aproximadamente Reader
de Projetos gerenciamento de 25 segundos a 56K
projetos e ferramentas
Cursos nos Listagem dos mais atuais 519KB Adobe PDF Inglês Cursos.pdf
Estados Unidos programas de treinamento aproximadamente
disponíveis nos Estados 2 minutos a 56K
Unidos
PMI
Tamanho Nome
Nome Descrição do arquivo Formato Idioma Arquivo
Apresentação Apresentação sobre 211KB Adobe PDF Português Pmi.pdf
PMI o PMI aproximadamente
45 segundos a 56K
Paper PMI Texto sobre o PMI 115KB Adobe PDF Português Pmi paper.pdf
descrevendo sua aproximadamente
finalidade, 25 segundos a 56K
características,
benefícios e certificação
Paper PMI Texto sobre o PMI 111KB Microsoft Português Pmi paper.lit
descrevendo sua aproximadamente Reader
finalidade, 25 segundos a 56K
características,
benefícios e certificação

INFORMAÇÕES COMPLEMENTARES
APÊNDICE B 415
METODOLOGIA PMBOK GUIDE DO PMI
Tamanho do Nome
Nome Descrição arquivo Formato Idioma Arquivo
Fluxo Processos Apresenta os 39 processos 134KB Adobe PDF Inglês Project
PMBOK do PMBOK Guide 2000 aproximadamente Management
(colorido) em uma rede de processos 30 segundos a 56K Process 2000
interligados com suas Eng color.pdf
entradas, ferramentas e
saídas, com cores diferentes
para cada área de
conhecimento.
Fluxo Processos Apresenta os 39 processos 134KB Adobe PDF Inglês Project
PMBOK (P&B) do PMBOK Guide 2000 aproximadamente Management
em uma rede de processos 30 segundos a 56K Process 2000
interligados com suas Eng black.pdf
entradas, ferramentas e
saídas.
Fluxo Resumido Apresenta os 39 processos 162KB Adobe PDF Português Fluxo
do Projeto interligados de forma aproximadamente Resumido de
resumida, com apenas o 35 segundos a 56K Processos –
título de cada processo. Tipo 1.pdf
Fluxo Resumido Apresenta os 39 processos 72KB Adobe PDF Português Fluxo
do Projeto 2 em uma tabela de fases, aproximadamente Resumido de
com cores diferentes para 15 segundos a 56K Processos –
cada área de conhecimento. Tipo 2.pdf
Processos Apresenta os 39 processos 117KB Microsoft Português Descritivo
PMBOK Guide do PMBOK com aproximadamente Reader processos
descritivo, entradas, 25 segundos a 56K area.lit
ferramentas e produtos
por área de conhecimento
A New Slides apresentados em 1.603KB Adobe PDF Inglês A New
Approach to novembro de 2001 aproximadamente Approach to
o
PMBOK durante o 32 Annual 6 minutos a 56K PMBK Guide
Guide 2000 PPT Project Management 2000
Institute Seminars & (ppt).pdf
Symposium em Nashville.
Apresenta uma nova
proposta de PMBOK Guide
em que os processos são
agrupados em fases do
projeto.

Tamanho do Nome
Uma Nova Visao Slides apresentados em 1.329KB Adobe PDF Português Uma Nova
do PMBOK novembro de 2001 aproximadamente Visao do
o
Guide 2000 PPT durante o 32 Annual 5 minutos a 56K PMBOK
Project Management Guide.pdf
Institute Seminars &
Apresenta uma nova
projeto.
A New Artigo apresentado em 172KB Adobe PDF Inglês A new
Approach to novembro de 2001 aproximadamente Approach to
o
PMBK Guide durante o 32 Annual 40 segundos a 56K PMBok Guide
2000 Paper Project Management 2000
Institute Seminars & (paper).pdf
Apresenta uma nova
proposta de PMBOK
Guide em que os processos
são agrupados em fases do
projeto.
A New Artigo apresentado em 115KB Microsoft Inglês A new
Approach to novembro de 2001 aproximadamente Reader Approach to
o
PMBK Guide durante o 32 Annual 25 segundos a 56K PMBok Guide
2000 Paper Project Management 2000
Institute Seminars & (paper).lit
Apresenta uma nova
projeto.

APÊNDICE B 417
CERTIFICAÇÕES PMI
Tamanho do Nome
PMP Guia oficial do PMI 377KB Adobe PDF Inglês PMP
Certification Headquarters com todas aproximadamente Certification
Handbook as informações sobre a 1 minuto a 56K Handbook.pdf
certificação PMP (Project
Management Professional)
Certificação PMP Apresentação realizada 5.300KB Adobe PDF Inglês PMP
por Rebecca Winston, aproximadamente Certification.pdf
chair do PMI-HQ, sobre 19 minutos a 56K
a certificação PMP
CAQ Guia oficial do PMI 541KB Adobe PDF Inglês PMOCAQ
Certification Headquarters com todas aproximadamente Handbook.pdf
Handbook as informações sobre a 2 minutos a 56K
certificação CAQ (Certified
of Added Qualification)
CAPM Guia oficial do PMI 487KB Adobe PDF Inglês PDC_CAPM
Certification Headquarters com todas aproximadamente Handbook.pdf
Handbook as informações sobre a 2 minutos a 56K
certificação CAPM
(Certified Assistant Project
Manager)
Bibliografia PMP Listagem dos livros 131KB Adobe PDF Português Bibliografia
oficiais recomendados aproximadamente PMP.pdf
pelo PMI para o exame 30 segundos a 56K
PMP
Bibliografia PMP Listagem dos livros 111KB Microsoft Português Bibliografia
oficiais recomendados aproximadamente Reader PMP.lit
pelo PMI para o exame 25 segundos a 56K
PMP
Simulado PMP Programa executável 1.129KB Programa Inglês cert.zip
com simulados do aproximadamente Executável
exame PMP 4 minutos a 56K compactado
(zip)

REPORTS REGIONAIS SOBRE GERENCIAMENTO DE PROJETOS
Tamanho do Nome
Report Brasil Relatório sobre a 146KB Adobe PDF Inglês Report Brasil
1999 maturidade do aproximadamente 1999.pdf
gerenciamento de projetos 30 segundos a 56K
no Brasil apresentado em
1999 para o PMI no PMI
Global Fórum
Report Brasil Relatório sobre a 114KB Microsoft Inglês Report Brasil
1999 maturidade do aproximadamente Reader 1999.lit
gerenciamento de projetos 25 segundos a 56K
no Brasil apresentado em
1999 para o PMI no PMI
Global Fórum
Report Brasil Relatório sobre a 3.499KB Adobe PDF Inglês Report Brasil
2002 maturidade do aproximadamente 2002.pdf
gerenciamento de 12 minutos a 56K
projetos no Brasil
apresentado em 2002
para o PMI no PMI
Global Assembly
Report Brasil Relatório sobre a 3.480KB Adobe PDF Português Report Brasil
2002 maturidade do aproximadamente 2002P.pdf
gerenciamento de 12 minutos a 56K
projetos no Brasil
apresentado em 2002
para o PMI no PMI Global
Assembly

APÊNDICE B 419
PALESTRAS E ARTIGOS SOBRE GERENCIAMENTO DE PROJETOS
Tamanho do Nome
A Busca pela Palestra motivacional 1.489KB Adobe PDF Português A Busca pela
Excelência em que trata do aproximadamente Excelencia
Gerenciamento gerenciamento de 5 minutos a 56K em Geren-
de Projetos projetos e seus mitos ciamento de
Projetos.pdf
Gerenciamento Palestra sobre 3.462KB Adobe PDF Português Gerencia-
de Projetos: gerenciamento de aproximadamente mento de
Um Enfoque projetos com enfoque 12 minutos a 56K GPgerencial.pdf
Gerencial gerencial, incluindo
questões conceituais e
influência da estrutura
organizacional no sucesso
do projeto
Project Apresentação com os 3.299KB Adobe PDF Português Virtual
Management conceitos de PMO e aproximadamente PMO.pdf
Office e Virtual enfoque para as 12 minutos a 56K
Project operações virtuais:
Management diferenças e desafios
Office (VPMO) para se estabelecer um
escritório de projetos
geograficamente distribuído
Gerenciamento Apresentação sobre os 2.175KB Adobe PDF Português Gp adm
de Projetos na principais desafios no aproximadamente publica.pdf
Administração que tange o gerenciamento 8 minutos a 56K
Pública de projetos na
administração pública,
bem como apresentação
dos resultados da pesquisa
do CEBELA sobre o assunto
Novas Apresentação básica 2.829KB Adobe PDF Português Novas
Fronteiras do sobre gerenciamento de aproximadamente Fronteiras.pdf
Gerenciamento projetos, incluindo as 10 minutos a 56K
de Projetos nove áreas de conhecimento
e conceitos básicos de PMO
Earned Value – Apresentação básica e 1.156KB Adobe PDF Inglês EVA
Analysis introdutória da análise aproximadamente Ingles.pdf
de valor agregado 4 minutos a 56K
Análise de Valor Apresentação básica e 1.841KB Adobe PDF Português EVA
Agregado introdutória da análise aproximadamente Portugues.pdf
de valor agregado 7 minutos a 56K

Tamanho do Nome
Managing ERP Artigo apresentado na 631KB Adobe PDF Inglês Managing
Implementation Filadélfia em 1999 durante aproximadamente ERP
Using Basic o 30º PMI 2 minutos a 56K Implementati
Software Tools Annual Symposium. on.pdf
and Web Ele apresenta um modelo
Scheduling de controle de
implementação de ERP
baseado em Web
Managing ERP Artigo apresentado na 269KB Microsoft Inglês Managing
Implementation Filadélfia em 1999 aproximadamente Reader ERP
Using Basic durante o 30º PMI 1 minuto a 56K Implementati
Software Tools Annual Symposium. on.lit
and Web Ele apresenta um modelo
Scheduling de controle de
implementação de ERP
baseado em Web
Como Executar Apresentação sobre as 2.434KB Adobe PDF Português Comunic
o Plano de novas tendências no aproximadamente web.pdf
Comunicação gerenciamento das 9 minutos a 56K
em Ambiente comunicações em projetos
Web e suas implicações quando
utilizada através de meios
virtuais
Controle Físico Apresentação realizada 1.589KB Adobe PDF Português Controle
e Orçamentário na Sociedade Mineira de aproximadamente Físico
de Obras com o Engenharia sobre as 6 minutos a 56K obras.pdf
Microsoft perspectivas do controle
Project físico e orçamentário de
obras utilizando o Microsoft
Project
Desmistificação Apresentação sobre as 1.952KB Adobe PDF Português Desmistificad
dos Custos de principais características aproximadamente o.pdf
Implementação de um implementador 7 minutos a 56K
SAP SAP e como a A&C pode
ser esse parceiro em
projetos
Gerenciamento Apresentação explicando 1.293KB Adobe PDF Português Ger Projetos
de Projetos de o motivo por que o aproximadamente ERP.pdf
Implementação gerenciamento de 5 minutos a 56K
de ERP projetos facilita e
viabiliza a implementação
de sistemas ERP

APÊNDICE B 421
MICROSOFT PROJECT E ENTERPRISE PROJECT MANAGEMENT
Tamanho do Nome
Microsoft Apresentação das 3.550KB Adobe PDF Inglês Microsoft
Project 2002 principais características aproximadamente Project
do Microsoft Project 13 minutos a 56K 2002.pdf
2002 Professional e Server
Microsoft Apresentação do produto 1.884KB Adobe PDF Português Microsoft
Project que revolucionou o aproximadamente Project
Central Mercado de 7 minutos a 56K Central.pdf
gerenciamento de projeto
e foi o antecessor do
Microsoft Project Server
Microsoft Apresentação das principais 1.969KB Adobe PDF Português Microsoft
Project 2000 características do Microsoft aproximadamente 7 Project
Project 2000 minutos a 56K 2000.pdf
OUTROS ARQUIVOS
Tamanho do
Nome Descrição arquivo Formato Idioma Nome Arquivo
RBS Riscos Matriz de 69KB Adobe PDF Português rbs riscos
Wideman identificação de aproximadamente wideman.pdf
riscos proposta 15 segundos a 56K
por Max Wideman
RBS Riscos Matriz de 71KB Adobe PDF Português wbs riscos
Kangari identificação de aproximadamente kangari.pdf
riscos proposta 15 segundos a 56K
por Kangari
Links Interessantes Relacionados a Gerenciamento de Projetos

http://www.pmi.org/info/PP_PMLinks.asp
http://www.aec.com.br/aeccom/gp/
http://www.businessinstitute.com.br/
http://www.fiap.com.br/
http://www.pmi.org/info/default.asp
http://www.allpm.com/
http://members.tripod.com/projmanctr/
http://www.pmreviewmagazine.com/
http://www.gantthead.com/Gantthead/default/
http://www.projectconnections.com/
http://www.esi-intl.com.br/
http://www.iil.com.br/

http://www.rmcproject.com/
http://www.pmlg.com/index.html
http://www.techrepublic.com/
http://www.pmforum.org/
http://www.pmisp.org.br
http://www.pmimg.org.br
http://www.pmidf.org/
http://www.pmipr.org.br/
http://www.pmiam.org/
http://www.pmi.org/info/GMC_ChapterListingUS.asp
http://www.pmi.org/info/GMC_ChapterListingOutsideUS.asp
http://www.infogoal.com/pmc/pmcswr.htm

APÊN D ICE C
Seleção de 50 conceitos
de gestão
Neste Apêndice você encontrará uma seleção de conceitos, os quais foram cunhados
nas últimas décadas por diversos gurus da administração moderna.
Gerentes e pessoas que lidam com projetos de TI e outras disciplinas preci-
sam estar cientes destes conceitos, pois têm a ver com o ambiente externo aos
projetos.
Após cada conceito você encontra referências bibliográficas para pesquisa e poste-
riores leituras. A maioria do títulos e dos autores já está traduzida no Brasil.
É importante conhecê-los para saber lidar com as mudanças e se manter atualizado.
1. Activity Based Costing

O método ABC (activity based costing) é uma técnica de contabilidade analítica nas-
cida no final dos anos 80. Permite determinar quais os custos indiretos a imputar a
um produto ou serviço consoante o tipo de atividade a que se referem. Os sistemas
tradicionais de contabilidade analítica repartem proporcionalmente os custos indire-
tos segundo critérios como o número de horas de trabalho manual, o número de ho-
ras por máquina ou a área ocupada por cada centro de custo. Segundo o método
ABC, os critérios de repartição desses custos diferem consoante o tipo de atividade.
Bibliografia
Comptabilité Analytique et de Gestion, Anne-Marie Reiser (Eska, 1994); e Implementing Activity Based Costing,
de Robin Cooper e Robert Kaplan (Harvard Business School Press, 1992).

2. Alianças estratégicas
São uma associação entre várias empresas que juntam recursos, competência e meios
para desenvolver uma atividade específica ou criar sinergias de grupo. Para conquis-
tar um novo mercado (geográfico ou setorial), adquirir novas competências ou ga-
nhar dimensão crítica, as empresas têm, em regra, três opções: a fusão ou a aquisi-
ção; a internacionalização; e a celebração de alianças estratégicas com um ou vários
parceiros. As alianças tanto podem efetuar-se entre empresas que atuam em ramos
de atividade diferentes como entre concorrentes. Distinguem-se das joint-ventures,
em que os parceiros partilham a propriedade de uma nova empresa.
Bibliografia
Getting Partnering Right, de N. Rackham, L. Friedman e R. Ruff (McGraw- Hill, 1996); Managing Mergers,
Acquisitions and Strategic Alliances, de S. Cartwright e C. Cooper (Heinemann, 1995); e Collaborating to
Compete, de J. Bleek e D. Ernst (Wiley & Sons, 1993).
3. Análise estrutural de indústrias

Michael Porter propõe um modelo de análise de indústrias baseado na identificação
de cinco forças. Eis uma breve descrição das questões a que deverá responder em
cada uma delas:
a. Ameaça de novas entradas – Existem barreiras à entrada de novos competidores?
b. Rivalidade entre os concorrentes – Há guerras de preços, de publicidade ou
de produtos?
c. Existência de produtos substitutos – Há uma ameaça de substituição por
produtos ou serviços que satisfaçam às mesmas necessidades?
d. Poder de negociação dos clientes – Qual o seu poder para influenciar as va-
riações de preço dos produtos ou serviços?
e. Poder de negociação dos fornecedores – Qual o seu poder de negociação
para elevar os preços ou reduzir o nível de qualidade oferecido?
Bibliografia
Competitive Strategy – Techniques for Analysing Industries and Competitor, de Michael Porter (The Free Press,
1990).
4. Análise SWOT
Criada por Kenneth Andrews e Roland Christensen, dois professores da Harvard
Business School, e posteriormente aplicada por numerosos acadêmicos a SWOT
Analysis, estuda a competitividade de uma organização segundo quatro variáveis:
strengths (forças), weaknesses (fraquezas), opportunities (oportunidades) e threats
(ameaças). Através desta metodologia poderá fazer-se a inventariação das forças e
fraquezas da empresa; das oportunidades e ameaças do meio envolvente e do grau de
adequação entre elas. Quando os pontos fortes de uma organização estão de acordo
com os fatores críticos de sucesso para satisfazer as oportunidades de mercado, a em-
presa será, por certo, competitiva no longo prazo.

SELEÇÃO DE 50 CONCEITOS DE GESTÃO
APÊNDICE C 425
Bibliografia
Field Guide to Strategy – A Glossary of Essencial Tools and Concepts of Today Managers, de Tim Hindle e Mar-
garet Lawrence (Harvard Business School Press, 1994); e The Concept of Corporate Strategy, de Kenneth
Andrews (Irwin,1971).
5. Análise de valor
É uma metodologia de gestão criada nos anos 50 pelo americano Lawrence Miles.
Consiste em decompor um produto ou serviço nas suas funções principais e, em segui-
da, delinear as soluções organizacionais mais apropriadas para reduzir os custos de pro-
dução. Implica uma análise detalhada do valor criado pela empresa através da distribui-
ção dos custos totais de um produto ou serviço pelas suas diferentes etapas: concepção,
fabricação, venda, distribuição e serviço aos clientes. Este conceito deu origem às no-
ções de cadeia de valor, de valor acrescentado do produto ou serviço e de shareholder
value (valor para o acionista) cuja autoria pertence a Alfred Rappaport.
Bibliografia
Valuation: Measuring and Managing the Value of Companies, de Tom Copeland, Tim Koller e J. Murrin (John
Wiley & Sons, 1995); The Search for Value, de Michael Ehrhardt (HBS Press, 1994); Creating Shareholder
Value, de Alfred Rappaport (The Free Press, 1986); e Analyse de la Valeur, de Bernard Adam (ESF, 1990).
6. Benchmarking
Segundo International Benchmarking Clearinghouse (IBC), o benchmarking é um
processo sistemático e contínuo de medida e comparação das práticas de uma organi-
zação com as das líderes mundiais, no sentido de obter informações que a possam
ajudar a melhorar o seu nível de desempenho. Ou seja, é uma técnica de observação e
adaptação das melhores práticas das melhores empresas, que, no entanto, não deve
ser confundida com a espionagem industrial. A Rank Xerox é considerada a empresa
pioneira na aplicação do benchmarking.
Bibliografia
The Benchmarking Implementation Guide, de James Harrington (McGraw- Hill, 1996); Benchmarking for Best
Pratices, de Christopher Bogan e Michael English (McGraw-Hill, 1994); Strategic Benchmarking, de Gre-
gory Watson (John Wiley & Sons, 1993); Benchmarking – A Signpost to Excellence in Quality and Producti-
vity, de Bengt Karlof e Svante Ostblom (Wiley, 1993); e The Benchmarking Book, de Michael Spendolini
(Amacom, 1992).
7. Brainstorming
É uma técnica para reuniões de grupo que visa ajudar os participantes a vencer as suas
limitações em termos de inovação e criatividade. Criada por Osborn em 1963, uma
sessão de brainstorming pode durar desde alguns minutos até várias horas, depen-
dendo das pessoas e da dificuldade do tema. Em regra, as reuniões não costumam ul-
trapassar os 30 minutos. O brainstorming tem quatro regras de ouro: nunca critique
uma sugestão; não encoraje as idéias bizarras nem prefira a quantidade à qualidade; e
não respeite a propriedade intelectual. Além de zelar para que todos os participantes

(geralmente entre seis e doze pessoas) cumpram as regras, o líder da sessão deve
manter um ambiente relaxante e propício à geração de novas idéias.
Bibliografia
Apllied Imagination, de A. F. Osborn (Scribner’s, 1963).
8. Brand Management
O conceito de brand management (gestão de marcas) significa o desenvolvimento sis-
temático do valor de uma marca. Longe vão os tempos em que era apenas uma fun-
ção de ligação entre o departamento de produção e as agências de publicidade. A par-
tir dos anos 80, as empresas começaram a considerar a imagem de marca como um
ativo estratégico das empresas (algumas atribuem-lhe um valor nas suas demonstra-
ções financeiras). O objetivo da gestão de marcas é criar uma identidade largamente
reconhecida pelo mercado-alvo a atingir. A atribuição de um nome ou uma marca a
um produto designa-se branding.
Bibliografia
Brand Chartering, de Chris Macrae (Addison-Wesley, 1996); Building Brands Directly, de Stewart Pearson
(Macmillan, 1996); Building Brand Identity, de Lynn Upshaw (John Wiley & Sons, 1995); Brand Power, de
Paul Stobart (Macmillan, 1994); e Brand Management, de David Arnold (Pitman, 1992).
9. Break-even
É um modo simples e eficaz de medir a rentabilidade (ou prejuízo) de uma empresa
ou de uma operação financeira. Permite igualmente fazer simulações alterando as
variáveis de cálculo. O objetivo desta análise é a determinação do break-even point
(ponto morto das vendas), no qual o valor das receitas da empresa (lucro de vendas)
é igual aos seus custos totais (somatório dos custos fixos e variáveis). Logo, esse será
o ponto de equilíbrio em que a empresa nem perde nem ganha dinheiro. Acima do
break-even point a empresa terá lucros, e abaixo dele terá prejuízos. Outro conceito
relevante é o da margem de contribuição (ponto em que as receitas igualam os custos
variáveis).
Bibliografia
Break-Even Analysis – Basic Models, Variants, Extensions, de Marcell Schweitzer, Ernst Trossmann e Gerald
Lawson (John Wiley & Sons, 1992); e Principles of Corporate Finance, de Richard Brealey e Stewart Myers
(McGraw-Hill, 1988).
10. Cadeia de valor

Designa a série de atividades relacionadas e desenvolvidas pela empresa para satisfa-
zer às necessidades dos clientes, desde as relações com os fornecedores e ciclos de
produção e venda até a fase da distribuição para o consumidor final. Cada elo dessa
cadeia de atividades está ligado ao seguinte. Esta é uma metodologia usada pela con-
sultora McKinsey, sistematizada e popularizada por Michael Porter, que permite de-
compor as atividades (divididas em primárias e de suporte) que formam a cadeia de

APÊNDICE C 427
valor. Segundo Porter, existem dois tipos possíveis de vantagem competitiva (lide-
rança de custos ou diferenciação) em cada etapa da cadeia de valor.
Bibliografia
Competitive Strategy – Techniques for Analysing Industries and Competitor, de Michael Porter (The Free Press,
1990).
11. Ciclo de vida do produto

O ciclo de vida de um produto no mercado pode ser dividido em quatro fases:
1. Introdução – O produto foi lançado no mercado e o crescimento das vendas
é lento.
2. Crescimento – Há uma explosão da procura, uma melhoria dos lucros e o
produto tende a massificar-se. Chegam novos competidores.
3. Maturidade – O ritmo de crescimento das vendas dá sinais de abrandamen-
to. É uma fase em que as empresas tendem a entrar em guerras de preço e
publicidade.
4. Declínio – A procura entra em derrapagem, os lucros sofrem uma rápida
erosão em direção ao ponto zero. Grande parte dos competidores começa a
abandonar o mercado.
Bibliografia
Principles of Marketing, de Philip Kotler (Prentice-Hall, 1983); e Marketing Management, de Philip Kotler
(Prentice-Hall, 1966).
12. Core competence

O conceito surgiu em 1990, na Harvard Business Review, em artigo intitulado “The
Core Competence of the Corporation”, da autoria de Gary Hamel e C. K. Prahalad.
O primeiro é professor na London Business School e o segundo leciona na Universi-
dade de Michigan. Core competence designa as competências estratégicas, únicas e
distintivas de uma organização. Poderá ser, por exemplo, um conhecimento técnico
ou uma tecnologia específica que é suscetível de oferecer um valor único para os
clientes e que distingue a empresa das rivais. É o caso da competência da Sony em
técnicas de miniaturização ou da Honda na criação de motores. Para os autores, pou-
cas companhias poderão ser líderes mundiais em mais de cinco ou seis competências
estratégicas.
Bibliografia
Competing for the Future, de Gary Hamel e C. K. Prahalad (HBS Press, 1994).
13. Cultura organizacional

As empresas, assim como os países, têm uma cultura única. É, por isso, crucial que as
empresas divulguem de forma explícita os valores. Quando o fazem por escrito, o
documento chama-se declaração de missão. Para James Collins e Jeremy Porras, au-

tores do livro Feitas para durar, a razão por que algumas empresas têm sucesso a longo
prazo, enquanto outras acabam por desaparecer, está na cultura organizacional.
Nesta era de incerteza tudo deve ser posto em causa, à exceção dos valores. Esses
têm de ser imutáveis.
Bibliografia
Corporate Culture and Performance, de John Kotter e James Heskett (The Free Press, 1992); Organizational Cul-
ture and Leadership, de Edgar Schein (Jossey-Bass, 1985); The Art of Japonese Management, de Pascale e
Athos (Simon & Schuster, 1981); e Management – Tasks, Responsibilities, Pratices, de Peter Drucker (Harper
& Row,1973).
14. Downsizing
Nos anos 80, as grandes empresas cresceram de forma desordenada através da diver-
sificação para novos negócios. Criaram estruturas gigantescas para competir numa
era em que a velocidade e a flexibilidade são os dois requisitos-chave. Por isso, nos
anos 90 foram forçadas a reestruturar-se, um processo designado downsizing (um ter-
mo importado da informática). Aplicado à gestão significa a redução radical do tama-
nho da empresa, geralmente através do delayering (redução dos níveis hierárquicos)
ou da venda de negócios não estratégicos. As empresas ganham flexibilidade, e per-
dem burocracia e ficam mais próximas do mercado e dos clientes.
Bibliografia
Rethinking the Corporation, de Robert Tomasko (Amacom,1993); The Rightsizing Remedy, de C. F. Hendricks
(Irwin, 1992); Downsizing – Reshaping the Corporation for the Future (Amacom, 1990); e Surviving Cor-
porate Downsizing, de J. Allen (Wiley,1988).
15. Ecogestão
A idéia de uma empresa responsável perante o ambiente e a sociedade era apenas um
sonho dos ecologistas. Hoje, os governos investem em programas de apoio, criam
legislação mais eficaz e controlam a eficácia dessas medidas. Em muitos países há um
sistema de atribuição do selo ecológico aos produtos amigos do ambiente. Mas a mu-
dança decisiva teve origem na crescente preocupação ecológica dos consumidores,
cujos hábitos de compra passaram a premiar as empresas e os produtos respeitadores
do ambiente. Também a maioria das multinacionais está apostando nos produtos
verdes. Quem ganha somos todos nós.
Bibliografia
Ecomanagement, de Callenbach, Capra, Goldman e Marburg (Berrett-Koelher, 1993); The Ecology of Commerce,
de Paul Hawken (Harper Collins, 1993); The E Factor, de Joel Makower (Times Books, 1993); e Corporate
Realities and Environmental Truths, de Bennett, Freierman e George (Wiley, 1993).
16. Ética negocial

Podem os negócios ser éticos? Esse é um dilema que tem apaixonado muitas gerações
de gestores e acadêmicos. É um caso típico em que existe uma grande diferença entre

APÊNDICE C 429
a teoria e a prática. Embora a maioria das empresas se autoproclame ética e social-

mente responsável, poucas têm um comportamento que o justifique. O conceito de
ética negocial (business ethics) resume o conjunto de princípios e códigos de compor-
tamento moralmente aceitáveis nos negócios. Hoje é uma disciplina que passou a ser
ensinada nas melhores universidades mundiais.
Bibliografia
Can Ethics be Taught, de Thomas Piper, Mary Gentile e Sharon Parks (HBS Press, 1993); Good Intentions Aside,
de Laura Nash (HBS Press, 1993); e The Power of Ethical Management, de Kenneth Blanchard (Mor-
row,1988).
17. Excelência
Nasceu em 1982 com a publicação de Vencendo a crise, de Peters e Waterman, o livro
de gestão mais vendido de sempre. Para os autores, as empresas excelentes têm oito
características distintivas: inclinação para a ação; proximidade do cliente; autonomia
individual; aposta nas pessoas; criação de valores; envolvimento no que se domina;
simplicidade formal e existência em simultâneo de rigidez e flexibilidade. Mais im-
portante do que a seleção das empresas excelentes (a maioria deixou de o ser alguns
anos depois) e dos seus oito atributos (parte deles deixaram de ser respeitados por es-
sas mesmas empresas), a obra foi o símbolo da nova forma de encarar a gestão.
Bibliografia
In Search of Excellence, de Tom Peters e Robert Waterman (Harper & Row, 1982); e The Art of Japonese Manage-
ment, de Pascale e Athos (Simon & Schuster, 1981).
18. Empowerment
É um conceito de gestão associado ao trabalho de Rosabeth Moss Kanter, professora
em Harvard e ex-editora da Harvard Business Review. Segundo a autora, as empre-
sas que dão mais poder e autonomia aos seus trabalhadores são as que estão melhor
posicionadas para competir a longo prazo. O meio empresarial parece começar a le-
var a sério essa recomendação. O caso clássico da aplicação radical do empowerment
é o da empresa brasileira Semco, liderada por Ricardo Semler, o autor do livro Mave-
rick e de um polêmico artigo publicado na Harvard Business Review, intitulado “Mana-
ging Without Managers”.
Bibliografia
Managing Empowerment, de Davis Jenkins (Century, 1996); The Pratice of Empowerment, de Dennis Kinlaw
(Gower, 1995), Maverick, de Ricardo Semler (Arrow, 1993); Zapp! The Lightning of Empowerment, de
William Byhnam (Fawcett, 1992); e When Giants Learn to Dance, de Rosabeth Moss Kanter (Routledge,
1989).

19. Equipes autogeridas

As self management teams (equipes autogeridas) são compostas por um pequeno nú-
mero de pessoas responsáveis por um processo operacional e os seus resultados. Elas
têm os meios para resolver problemas relativos à execução do trabalho e geram a di-
visão e o planejamento das tarefas do grupo. Foi um conceito na moda nos anos 70,
mas cujo entusiasmo decresceu na última década, visto que os resultados da aplicação
nem sempre foram os desejados. Hoje tem novamente mais adeptos, devido à cres-
cente qualificação dos recursos humanos.
Bibliografia
Competitive Advantage Through People, de Jeffrey Pfeffer (HBS Press, 1994); Inside Teams, de Richard Wellins,
William Byham e George Dixon (Jossey-Bass, 1994); The Wisdom of Teams, de Jon Katzenbach e Douglas
Smith (HBS Press, 1993); e Effective Leadership, de John Adair (Gower, 1983).
20. Franchising
É um método popular para uma empresa alargar a sua base de clientes sem necessitar
investir capital e para um candidato a empresário criar um negócio sem constituir
uma empresa de raiz. Há dois parceiros envolvidos: o franquiador, que desenvolveu
o negócio e lhe deu o nome; e o franquiado, que compra o direito de operar sob esse
nome. Um negócio torna-se franchising quando o franquiado paga direitos de entra-
da e royalties (geralmente uma percentagem fixa do volume de negócios) pela utili-
zação da marca, produto ou serviço. Em contrapartida, recebe apoio do franquiador
e o direito a distribuir o produto ou serviço numa área determinada.
Bibliografia
Franchising for Free, de Dennis Foster (Wiley, 1988); Blueprint for Franchising a Business, de Steven Raab e
Gregory Matusky (Wiley, 1987); e Comment Réussir en Franchise, de Max de Mendez e Jean-Paul Lehnisch
(Dunod, 1989).
21. Fidelização de clientes

Engloba as técnicas destinadas a conservar e atrair os melhores clientes de modo a au-
mentar a sua fidelização à empresa. Vários estudos já demonstraram que recrutar no-
vos clientes é três a cinco vezes mais caro do que conservar os existentes e encora-
já-los a consumir mais. Aumentar a fidelidade exige detectar as principais causas de
insatisfação dos consumidores, nomeadamente as razões que os levaram a recusar
um produto ou serviço ou a preferir o de um concorrente. Em seguida, as empresas
devem corrigir esses pontos e melhorar a qualidade oferecida aos clientes em todas as
áreas. A meta final é criar uma organização totalmente orientada para o cliente (cus-
tomer-driven company).
Bibliografia
The One-to-One Future, de Don Peppers e Martha Rodgers (Piatkus, 1994); e The Customer-Driven Company,
de Richard Whitely (Addison-Wesley, 1991).

APÊNDICE C 431
22. Globalização
As tecnologias de informação deram origem a uma verdadeira aldeia global. Para os
gestores, o termo significa a integração mundial das atividades de uma organização.
É uma etapa mais avançada da internacionalização, em que os processos são organiza-
dos à escala global, como se o mundo fosse um único país. A globalização diz respeito
a todas as funções da empresa, mas muitas vezes é apenas limitada ao marketing.
Nessa área, Theodore Levitt foi o primeiro guru a alertar para a homogeneidade glo-
bal das preferências dos consumidores.
Bibliografia
World Class, de Rosabeth Moss Kanter (Simon & Schuster, 1995); The Evolving Global Economy, de Kenichi
Ohmae (HBS Press, 1995); The Borderless World, de Kenichi Ohmae (Harper & Row, 1990); Managing
Across Borders, de Christopher Bartlett e Sumantra Goshal (HBS Press, 1989); e The Multinacional Mission,
de C. K. Prahalad e Yves Doz (The Free Press, 1987).
23. Gestão da mudança

A idéia não é propriamente nova. O que mudou foi a própria natureza da mudança,
que de incremental e passível de previsão passou a descontínua, veloz e imprevisível.
Segundo o livro Fast Forward, tema de capa desta edição, as três forças geradoras da
mudança são as tecnologias, a desregulamentação e a globalização. Os gestores de-
vem preparar-se para a mudança através da resposta a três perguntas fundamentais:
Como será a organização do futuro? Qual o processo de mudança ideal? Qual o tipo
de competências que é necessário?
Bibliografia
Fast Forward, de James Champy e Nithin Nohria (HBS Press, 1996); Managing in a Time of Great Change, de
Peter Drucker (Heinemann, 1995); Crazy Times Calls for Crazy Organizations, Tom Peters (Alfred Knopf,
1995); Liberation Management (Alfred Knopf, 1990); e A Force for Change, de John Kotter (The Free Press,
1990).
24. Gestão por objetivos

Criada por Peter Drucker nos anos 50, a gestão por objetivos (management by objecti-
ves – MBO) descreve um sistema de gestão em que os trabalhadores e os gestores de
topo definem em conjunto qual é o objetivo final do seu trabalho, como o realizar, de
que forma será avaliado e qual o tempo necessário à concretização. É uma técnica po-
pular em todo o mundo. Há, no entanto, três críticas clássicas à sua aplicação: os ges-
tores tendem a definir metas pouco ambiciosas ou irrealistas; os objetivos raramente
resultam de um processo participativo e descentralizado; e não promove o trabalho
de equipe.
Bibliografia
Management – Task, Responsabilities, Pratices, de Peter Drucker (Harper & Row, 1973); Managing for Results,
de Peter Drucker (Heinemann, 1964); The Pratice of Management, de Peter Drucker (Harper & Row, 1954);
e Concept of the Corporation, de Peter Drucker (John Day, 1946).

25. Horizontal Organization

Uma organização horizontal (horizontal organization) ou achatada (flat organization) é
a que minimiza o número de níveis hierárquicos de modo a estar mais perto dos
clientes; nessa organização os trabalhadores estão também mais próximos dos níveis
de decisão. É um conceito que propõe acabar com a pirâmide hierárquica das organi-
zações tradicionais. A sua vantagem principal é tornar os circuitos de decisão mais
curtos, logo mais rápidos. Os empregados, sentindo-se menos vigiados, revelam
maior empenhamento e criatividade. Esse tipo de organização favorece a criação de
estruturas matriciais, mais leves e flexíveis, em que existe uma maior descentraliza-
ção das responsabilidades.
Bibliografia
Global Strategies, de Percy Barnevik e Rosabeth Moss Kanter (HBS Press, 1994).
26. Internet e intranet

A Internet é uma ferramenta ao alcance dos gestores que lhes permite mudar radical-
mente a forma como executam o trabalho e gerem empresas. Se a Internet já provou
ser crucial para comunicação e dar acesso à informação, as intranets (redes internas)
são cada vez mais populares para a difusão da informação no interior da empresa en-
tre os seus funcionários. Outras das facilidades das intranets são a criação de grupos
de discussão internos (newsgroup), que visam partilhar informação e recolher idéias
ou sugestões, bem como o correio eletrônico (interno e externo), que se está assu-
mindo em todo o mundo como uma alternativa ao envio de mensagens por fax.
Bibliografia
Global Advantage on the Internet, de Mary Cronin (VNR, 1996); Marketing Internet, de Jill e Matthew
Ellsworth (Wiley, 1995); e Being Digital, de Nicholas Negroponte (Alfred Knopf, 1995).
27. Just-in-time
É uma técnica de gestão e controle de mercadorias que procura minimizar o nível de
stocks nos armazéns das empresas industriais. Criada em 1960 pela nipônica Toyota,
foi considerada como uma das ferramentas de gestão que mais contribuíram para o
milagre industrial japonês. A idéia base é bastante simples: cada etapa do ciclo de
produção só deve solicitar novas encomendas à etapa anterior na medida em que pre-
cisar delas. Implica igualmente uma redução do número de fornecedores. Richard
Schonberger foi o primeiro autor a divulgar a metodologia just-in-time nos Estados
Unidos.
Bibliografia
JIT II, de Lance Dixon e Anne Millen Porter (Purchasing Magazine, 1994); Building a Chain of Customers, de
Schonberger (The Free Press, 1990); Total Quality Control, de Feigenbaum (McGraw-Hill, 1983); e Japo-
nese Manufacturing Techniques, de Schonberger (The Free Press, 1982).

APÊNDICE C 433
28. Lean prodution

Engloba o conjunto de técnicas desenvolvidas nos anos 70 por fabricantes japoneses,
como a Toyota e a Matsushita, para reduzir os custos de produção e aumentar a com-
petitividade. Foi popularizado através do estudo sobre a indústria automobilística do
MIT, designado “The Machine that Change the World”, que investigou as causas as-
sociadas à superiodade dos nipônicos nos domínios da produtividade, flexibilidade,
rapidez e qualidade. O conceito de lean prodution é baseado em quatro princípios:
trabalho de equipe; comunicação; uso eficiente de recursos e eliminação de desper-
dícios e melhoria contínua (a que os japoneses chamam kaisen).
Bibliografia
The Machine That Change the World – The Story of Lean Prodution, de James Womack, Daniel Jones e Daniel
Ross (Harper Collins, 1990).
29. Learning organization

Criado por Chris Argyris, professor em Harvard, designa por learning organizations
(organização em constante aprendizagem) as empresas que aprendem à medida que os
seus trabalhadores vão ganhando novos conhecimentos. O conceito é baseado na idéia
de Argyris, chamada double-loop learning (quando os erros são corrigidos através da al-
teração das normas empresariais que o causaram). Em 1990, Peter Senge, professor do
MIT, popularizou o conceito através do best-seller A Quinta Disciplina.
Bibliografia
Organizational Learning II, de Chrys Argyris e Donald Schon (Addison-Wesley, 1996), The Fifth Discipline Fi-
eldbook, de Peter Senge, Art Kleiner, Charlotte Roberts, Richard Ross e Bryan Smith (Nicholas Brealey,
1994); The Learning Organization, de Bob Garrat (Harper Collins, 1994); e The Fifth Discipline – The Art
and Pratice of a Learning Organization, de Peter Senge (Century Business, 1990).
30. Liderança
Existem características básicas para que um indivíduo possa tornar-se um líder, tais
como visão, integridade (conhecimentos, autoconfiança e maturidade) e vontade de
assumir riscos. Os líderes são, em regra, pessoas muito persistentes, com grande ca-
risma e motivadas pelo seu instinto. Segundo Warren Bennis, “um bom gestor faz as
coisas bem, enquanto um bom líder faz as coisas certas”. Enquanto para o britânico
John Adair as capacidades de liderança podem ser adquiridas através do treino, para
o norte-americano John Kotter, elas são inatas, embora todas as pessoas devam ser
encorajadas a ser líderes.
Bibliografia
Maximum Leadership, de Philippe de Backer e Allen Sheppard (Orion, 1995), Real Change Leaders, de Jon Kat-
zenbach (Nicholas Brealey, 1996); Reinventing Leadership, de Warren Bennis e Robert Townsend (Piatkus,
1996); On Becoming a Leader, de Warren Bennis (Hutchingson, 1989); e Leadership an Art, de Max de Pree
(Doubleday, 1989).

31. Matriz BCG

Da autoria da consultora Boston Consulting Group é um instrumento analítico de
apoio à tomada de decisões estratégicas, caso das relativas ao portfolio (carteira) de
negócios ou produtos. O modelo BCG é um dos pioneiros e sem dúvida o mais popu-
lar devido à sua simplicidade. Para aplicar será necessário construir uma matriz, cujo
eixo horizontal é representado pela variável quota de mercado relativa (alta à esquer-
da e baixa à direita), e no eixo vertical está a taxa de crescimento do mercado (eleva-
da em cima e reduzida em baixo). A matriz dá origem a quatro quadrantes: interro-
gações (question-marks); estrelas (stars); vacas leiteiras (cash-cows); e cães (dogs).
Bibliografia
The Logic of Business Strategy, de Bruce Henderson (Ballinger, 1984); e Strategic Market Planning, de Abel e
Hammond (Prentice-Hall, 1979).
32. Marketing-Mix
Representa o conjunto de variáveis controláveis pela empresa para influenciar as res-
postas dos consumidores. Nos anos 60, Jerome McCarthy divulgou o conceito, divi-
dindo-o em “4 Ps”: produto (product), preço (price), promoção (promotion) e pon-
to de venda (point of sale). A variável promoção inclui publicidade, promoção de
vendas, publicity (comunicação noticiosa), relações públicas, sponsoring (patrocínio),
marketing direto (direct-mail e telemarketing). A variável ponto de venda requer a
análise de fatores como estrutura de canais de distribuição, tipo de distribuição,
merchandising (ações de marketing no ponto de venda), logística de distribuição e de
stocks e gestão da força de vendas.
Bibliografia
Marketing Management, de Philip Kotler (Prentice-Hall, 1971, 7.ª edição); Basic Marketing – A Managerial
Approach, de Jerome McCarthy (Irwin, 1960).
33. Motivação
Nasceu no final dos anos 20 através das experiências do australiano Elton Mayo. O
fundador da escola de relações humanas (uma filosofia oposta aos princípios científi-
cos do trabalho de Taylor) pretendia provar que os trabalhadores não eram motiva-
dos apenas pela remuneração, mas também por outros fatores como as condições de
trabalho e o apreço das chefias. Nos anos 50, dois autores deram uma contribuição
decisiva para essa corrente: Abraham Maslow (pirâmide das necessidades) e Frede-
rick Herzberg (teoria dos dois fatores).
Bibliografia
Marie Parker Follet – Prophet of Management (HBS Press, 1995); Organizational Psichology, de E. Schein
(Prentice-Hall, 1980); The Human Side of the Enterprise, de D. McGregor (McGraw-Hill, 1960); Motiva-
tion and Personality, de A. Maslow (Harper & Row, 1954); e The Human Problems of an Industrial Civilisa-
tion, de E. Mayo (HBS Press, 1933).

APÊNDICE C 435
34. Networking
Um termo importado da informática relativo à ligação entre terminais de computa-
dor para que o acesso aos dados possa ser partilhado por diversos utilizadores. O me-
lhor exemplo de networking à escala global é o da Internet, que permite a ligação em
rede e on-line (em tempo real) entre um ou vários indivíduos localizados em qual-
quer ponto do mundo. É uma expressão que pode igualmente designar a forma como
as grandes companhias de serviços (auditoras, consultoras, agências de publicidade,
ou firmas de advogados) podem-se internacionalizar sem recorrer à abertura de no-
vas delegações regionais.
Bibliografia
The Road Ahead, de Bill Gates (Penguin, 1995); The Age of Paradox, de Charles Handy (Hutchisom, 1993);
Networks and Organizations, de Nitin Nohria e Robert Eccles (HBS Press, 1993); e Telecommuting, de Joel
Kugelmass (The Free Press, 1995).
35. Outplacement
Os grupos empresariais têm passado por reestruturações associadas a demissões ma-
ciças. Neste contexto, há um novo negócio a florescer, o outplacement. É uma téc-
nica de gestão de recursos humanos que visa apoiar os trabalhadores dispensados
rumo à sua reinserção profissional. As consultoras em outplacement fornecem acon-
selhamento financeiro e formação em recrutamento e seleção. Há quem prefira criar
centros de outplacement internos, que prestam auxílio aos trabalhadores dispensa-
dos e aos que são recolocados em novas funções.
Bibliografia
The Frontiers of Excellence, de Robert Waterman (Nicholas Brealey, 1994); The International Relocation, de
Coyle e Shortland (Heinemann, 1992); The Middle Management Challenge, de Frohmann e Leonard
(McGraw-Hill, 1993); Winning Carreer Moves, de Geraldine Henze (Irwin, 1992); e The Outplacement So-
lution, de Wolfer e Wong (Wiley, 1988).
36. Outsourcing
Trata-se de contratar uma entidade exterior à empresa para executar serviços não
estratégicos (que não produzem valor acrescentado para os clientes), em vez de pro-
duzi-los internamente. A grande vantagem reside na redução de custos que tal opção
implica. Talvez ainda seja mais importante o fato de o outsourcing libertar mais tem-
po os executivos para se dedicarem mais às core competences (competências estra-
tégicas) da empresa. O conceito nasceu na área das tecnologias de informação. Tem
maior potencial de aplicação em indústrias dinâmicas, em que as pressões para cortes
nos custos são mais intensas, nomeadamente nos grupos empresariais que preten-
dem seguir uma estratégia de integração vertical das suas atividades.
Bibliografia
Information Systems Outsourcing, de Mary Lacity e Rudy Hirschheim (Wiley, 1995).

37. Princípios de humor e bom senso

Eis três desses princípios:
1. Análise de Pareto – Criada no século XIX, pelo economista italiano Vilfredo
Pareto, defende que cerca de 80% dos lucros de uma empresa são derivados
de 20% dos seus produtos.
2. A lei de Parkinson – Foi o primeiro livro humorístico sobre gestão. Eis duas
das suas leis: “O trabalho expande-se na exata medida do tempo disponível
para ser feito”; “Quanto menor o interesse do assunto, maior é a discussão”;
3. Princípio de Peter – Defende que qualquer trabalhador acabará por ser pro-
movido até ao limite máximo do seu nível de incompetência. Foi criado em
1969 por Laurence J. Peter.
Bibliografia
Parkinson’s Law or the Pursuit of Progress, de Northcote Parkinson (Penguin, 1957); e The Complete Murphy’s
Law, de Arthur Block (Price Sloan, 1977).
38. Pensamento estratégico

As décadas de 70 e 80 foram a época áurea do planejamento estratégico. Na prática, a
maioria desses planos acabou por fracassar. Henry Mintzberg diagnosticou os moti-
vos. Segundo o canadense, o excesso de análise cria uma espécie de paralisia. Por ou-
tro lado, considera que não se deve separar o planejamento da ação. Enquanto pla-
nejar é um exercício analítico, a estratégia baseia-se na criatividade, intuição e capa-
cidade de síntese. Para designar esta última atitude se propõe, em alternativa, o ter-
mo “pensamento estratégico”.
Bibliografia
The Strategy Process, de Henry Mintzberg, James Brian Quinn e Sumantra Goshal (Prentice-Hall, 1995); Stra-
tegy, de Cynthia Montgomery e Michael Porter (HBS Press, 1991); The Mind of the Strategist, de Kenichi
Ohmae (McGraw-Hill, 1992); The Rise and Fall of Strategic Planning, de Henry Mintzberg (The Free Press,
1994); e Mintzberg on Management, de Henry Mintzberg (The Free Press, 1989).
39. Pensamento lateral

Criado por Edward de Bono, o conceito de pensamento lateral consiste na geração
de novas idéias e no abandono das obsoletas. Aplicado às empresas é uma técnica para
aumentar a criatividade e um recurso estratégico da organização. Em sua opinião, é
necessário estimular o cérebro através da atitude de quebrar os princípios estabeleci-
dos e passar a encarar a realidade de um modo diferente. De Bono distingue o pensa-
mento lateral (descontínuo e destinado à geração de idéias) do vertical (contínuo e
orientado para desenvolvê-las). Enquanto o pensamento lateral dá idéias, o vertical
desenvolve-as.
Bibliografia
Teach Yourself to Think, de Edward de Bono (Viking, 1995); NLP At Work, de Sue Knight (Nicholas Brealey,

APÊNDICE C 437
1995); I Am Right, You Are Wrong, de Edward de Bono (Viking, 1990); Lateral Thinking for Management,
de Edward de Bono (McGraw-Hill, 1971), e The Use of Late-ral Thinking, de Edward de Bono
40. Planejamento por cenários

A velocidade da mudança obriga os gestores a encarar uma dura realidade: é cada vez
mais difícil (senão impossível) prever as ocorrências no meio envolvente a longo pra-
zo. Peter Schwartz popularizou a técnica que permite resolver o problema: o plane-
jamento por cenários. Através dela, a Shell foi a única empresa do setor preparada
para a crise do petróleo de 1973. Os cenários não são previsões. Construídos a partir
da geração de hipóteses alternativas sobre o futuro, permitem às empresas estar pre-
paradas para a ocorrência de cada uma dessas hipóteses e exercitam os gestores a re-
fletir sobre as estratégias de longo prazo.
Bibliografia
The Art of the Long View, de Peter Schwartz (Doubleday, 1991).
41. Project management

A gestão de projetos (project management) é baseada na formação de equipas tempo-
rárias e pluridisciplinares. Trata-se de um grupo de trabalho constituído por empregados
provenientes de diferentes sectores da empresa que tem um projeto a desenvolver e que
é validado pela direção-geral. Os membros devem ter especializações e competências di-
versas. A equipe deve ser colocada sob a responsabilidade de um chefe de projeto, que
depende diretamente da direção-geral. Os membros são desligados, total ou parcial-
mente, mas apenas de uma forma temporária, do seu serviço de origem.
Bibliografia
Project Management Demystified, de Geoff Reiss (E&FN Spon, 1996); Project Management, de Dennis Lock (Go-
wer, 1996); Project Management and Project Network Techniques, de Keith Lockyer e James Gordon (Pit-
mann, 1995); e Successful Project Managers, de Milton Rosenau (VNR,1991).
42. Qualidade total

Segundo o European Foundation for Quality Management (EFQM), os esforços para
a qualidade total (TQM – Total Quality Management) são caracterizados pelos se-
guintes fatores: excelência nos processos; cultura de melhoria contínua; criação de
um melhor relacionamento com os clientes e fornecedores; envolvimento de todos
os trabalhadores e clara orientação para o mercado. Os melhores exemplos da apli-
cação da gestão da qualidade total são as empresas japonesas, que ironicamente tive-
ram como mestres, nos anos 40 e 50, os americanos Deming e Juran.
Bibliografia
Quality is Still Free, de Philip Crosby (McGraw-Hill, 1996); Managerial Breakthrough, de Juran (McGraw-
Hill, 1995); Quality is Free, de Philip Crosby (McGraw-Hill, 1979); Out of the Crisis, de Edwards Deming
(Cambridge University Press, 1986); Juran on Planning for Quality, de Juran (The Free Press, 1988); e Total
Quality Control, de Feigenbaum (McGraw-Hill, 1983).

43. Reengenharia
Michael Hammer, ex-professor do MIT, é considerado o pai desta teoria inovadora e
radical. Referiu-se pela primeira vez ao tema no artigo publicado em 1990 pela Har-
vard Business Review. Mas a consagração só chegaria três anos depois com o livro Reen-
gineering the Corporation, escrito em parceria com James Champy. Para os autores, a
reengenharia significa um redesenho radical dos processos de negócio com o objeti-
vo de obter melhorias drásticas em três áreas: custos, serviços e tempo.
Bibliografia
The Reengineering Revolution, de Michael Hammer (Harper Collins,1995); Reengineering Management, de Ja-
mes Champy (Harper Collins, 1995); The Reengineering Handbook, de Raymond Manganelli e Mark Klein
(Amacom, 1994); Reengineering the Corporation, de Hammer e Champy (Harper Collins, 1993); e Process
Innovation, de Thomas Davenport (Harvard Business School Press, 1992).
44. Risk management

Ou gestão do risco, significa fazer a análise, controle e seguro ideal dos riscos de uma
empresa. Visa antecipar, analisar e valorizar os riscos de funcionamento da empresa
de modo a minimizá-los. O método inclui todos os tipos de riscos clássicos (seguran-
ça de pessoas e bens) e também alguns cuja freqüência ou amplitude cresceu nos últi-
mos anos, tais como riscos de cópias, os ligados ao meio ambiente ou as despesas mé-
dicas dos empregados.
Bibliografia
The Complete Guide to Business Risk Management, de Kit Sadgrove (Gower, 1995); Finantial Innovation and
Risk Sharing, de Franklin Allen e Douglas Gale (MIT Press, 1994); Des Primes d’Assurance au Financement
des Risques, Ives Maquet (Bruylant, 1991); e Risk Management and Insurance, de C. Williams e R. Heins
45. Sinergia
Refere-se à convicção de que dois mais dois podem ser cinco. Esta é uma não-
evidência que serviu para justificar as injustificáveis operações de fusão e aquisição
que caracterizaram o mundo dos negócios nos anos 80. O conceito de sinergia, in-
troduzido por Igor Ansoff no livro Corporate Startegy, procura provar que duas em-
presas juntas valem mais do que a soma das duas separadas. Se não existir sinergia (ou
se for negativa) não valerá a pena concretizar-se uma fusão ou aquisição. O conceito
pode ser aplicado em outras áreas, como alianças estratégicas, joint-ventures, acor-
dos de cooperação, relações das empresas com fornecedores ou clientes e equipes de
trabalho pluridisciplinares.
Bibliografia
Implementing Strategic Management, de Igor Ansoff (Pentice-Hall, 1984); e Corporate Strategy, de Igor Ansoff
(MCGraw-Hill, 1965).

APÊNDICE C 439
46. Trade marketing

Significa a otimização da relação entre o produtor e o distribuidor. O conceito surgiu
no início dos anos 90 devido à importância crescente dos intermediários (grossistas e
retalhistas) na distribuição. A relação entre produtores e distribuidores é, em regra,
conflituosa. O objetivo do trade marketing é encontrar formas para que ambos tirem
o máximo partido de um acordo de colaboração. Propõe a criação de uma parceria
de longo prazo entre produtores e distribuidores em áreas como trocas de informa-
ção, oferta do produto com a marca do distribuidor e publicidade ou promoções
conjuntas.
Bibliografia
Concurrent Marketing, de Frank Cespedes (HBS Press, 1996); Le Trade Marketing Mix, de Bruno Chevot e
Emmanuel Pouet (Presses du Management, 1995); e Le Trade Marketing, de Claude Chinardet (Éditions
d´Organizations, 1994).
47. Time Based Competition

Consiste na redução do tempo de resposta às evoluções do mercado. Hoje as empre-
sas devem fornecer ao cliente o que ele quer, no momento em que o deseja e não
mais tarde, senão será a concorrência a fazê-lo. Segundo os autores do conceito, os
norte-americanos George Stalk e Thomas Hout, do Boston Consulting Group, o
controle do tempo é a chave para um bom desempenho da empresa. Na atual conjun-
tura de mudança, só as empresas capazes de adaptar-se rapidamente podem conquis-
tar quotas de mercado. O poder de reação da companhia deve ser estimulado em to-
dos os campos: produtos; produção; distribuição; e serviço.
Bibliografia
Competing Against Time, de George Stalk e Thomas Hout (The Free Press, 1990); The Product Development
Challenge, de Kim Clark e Steven Wheelwright (HBS Press,1995); e Producy Juggernauts, de Jean-Philippe
Deschamps (HBS Press, 1995).
48. Urgente versus Importante

Existe um fosso entre as atividades que nos consomem tempo e aquelas que são real-
mente importantes. Os métodos tradicionais de gestão do tempo ensinam a fazer
mais coisas em menos tempo, ou seja, a ser mais eficiente em áreas como os compro-
missos, reuniões, horários, objetivos e atividades. Os nossos maiores desafios não
são, no entanto, resolvidos com a velocidade ou a quantidade de tarefas preenchidas.
São problemas de eficácia (satisfação das nossas metas prioritárias) e de ordem quali-
tativa. Enquanto os primeiros dizem respeito ao modo como gerimos o tempo, os
segundos referem-se à gestão das nossas vidas.
Bibliografia
First Thing First, de Steven Covey (Simon & Schuster, 1994); Seven Habits of Highly Effective People, de S. Co-
vey (Simon & Schuster, 1992); Time Trap, de Alec Mackenzie (Amacom, 1990); e Principle-Centered Lea-
dership, S.Covey (Simon & Schuster, 1990).

49. Vantagem competitiva

Michael Porter demonstrou que as empresas bem-sucedidas obedecem a padrões
definidos de comportamento que podem ser resumidos em três estratégias genéricas
(as fontes de vantagem competitiva sobre os concorrentes):
1. Liderança baseada no fator custo – Possuir custos mais baixos do que os con-
correntes.
2. Diferenciação – Criar um produto ou serviço que é visto na indústria como
único.
3. Focalização – Combinar as duas estratégias, direcionando-as para um alvo
específico.
Bibliografia
Strategy – Seeking and Securing Competitive Advantage, de Michael Porter (HBS Press, 1991); Competitive
Advantage – Creating and Sustaining Superior Performance, de Michael Porter (The Free Press, 1985); e
Competitive Strategy – Tecniques for Analyzing Industries and Competitors, de Michael Porter (The Free
Press, 1980).
50. X, Y, Z
Nascidas no final dos anos 50, as teorias X e Y são duas visões opostas sobre a natureza
humana e a forma de gerir a força de trabalho. Foram criadas pelo psicólogo Douglas
McGregor, do MIT. A teoria X assume que os indivíduos não gostam de trabalhar, a
menos que sejam obrigados coercivamente a fazê-lo. A teoria Y defende que as pes-
soas têm auto-realização no trabalho e que cumprem melhor as suas tarefas se não fo-
rem vigiadas por terceiros. A teoria Z, de William Ouchi, é uma variante da teoria Y.
Defende que os trabalhadores têm um grau de envolvimento similar ao dos gestores
quando existe um sistema de recompensas e incentivos eficaz.
Bibliografia
Theory Z, de William Ouchi (Addison-Wesley,1981); The Professional Manager, de D. McGregor (McGraw-
Hill, 1967); e The Human Side of the Entreprise, de Douglas McGregor (McGraw-Hill, 1960).

APÊN D ICE D
Melhores práticas para gestão

de projetos governamentais
OBJETIVOS
Após a leitura deste Apêndice, você será capaz de:
Descobrir a existência de uma extensão governamental do PMBOK.
Saber por que a extensão governamental é necessária no cenário de gerencia-
mento de projetos neste tipo de indústria.
Constatar o objetivo da extensão governamental do PMBOK do PMI.
Identificar as esferas do governo.
Aplicar e adaptar processos de gerenciamento de projetos do PMBOK com en-
foque em projetos governamentais.
Saber como adquirir e ter acesso à extensão governamental.
O QUE VEREMOS A SEGUIR

A extensão governamental do PMBOK.
Por que a extensão governamental é necessária?
Qual o objetivo da extensão governamental?
O que faz projetos governamentais serem únicos?
Esferas do Governo.
Um exemplo de processo de gerenciamento de projetos da extensão governa-
mental.
Resumo do capítulo.
Referências Bibliográficas, Artigos e Web Sites.

A extensão governamental do PMBOK

Assim como no setor privado, a tecnologia da informação funciona como ferramenta
de apoio estratégico em praticamente “todos” os projetos do governo. Por isso, jul-
guei ser relevante a inserção de breves comentários sobre a extensão governamental
do PMBOK.
O PMI batizou as práticas de gerenciamento de projetos aplicadas à indústria go-
vernamental como Government Extension to A Guide to the Project Management Body of
Knowledge.
As práticas de gerenciamento de projetos governamentais devem ser estudadas e
utilizadas em conjunto com o PMBOK. No decorrer do texto da extensão governa-
mental de gerenciamento de projetos do PMI, várias são as referências que remetem
o leitor a buscar maiores detalhes e rever a parte conceitual no PMBOK. Um com-
plementa o outro, se a aplicação tiver enfoque na gestão de projetos do governo.
A Government Extension to A Guide to the Project Management Body of Knowledge é um
importante passo no comprometimento de continuidade do PMI para definir o con-
junto de conhecimentos para apoiar a profissão gerente de projetos, e para desenvol-
ver padrões para sua aplicação. Desde 1983, voluntários dedicados vêm trabalhando
no desenvolvimento destes padrões.
Tem sido intenção do PMI durante anos suplementar as informações do PMBOK
provendo extensões de indústrias específicas e práticas padronizadas. Ela descreve
os conhecimento e práticas que são “geralmente aceitas” para projetos governamen-
tais. É aplicada a projetos governamentais nacionais, estaduais e municipais.
Por que a extensão governamental é necessária?

Governos de todo mundo gastam vastas somas de dinheiro em seus projetos.
Esses projetos envolvem diversas indústrias, incluindo aeroespacial, defesa civil,
comunicações, tecnologias, construção, serviços financeiros, petroquímica, utilitá-
rios, energia e muitas outras.
Em cada uma dessas indústrias, recursos em comum são compartilhados entre os
projetos governamentais e projetos do setor privado, mas existem também recursos
compartilhados por todos os projetos governamentais que não ocorrem em projetos
do setor privado.
É de grande interesse de todos os contribuintes (as pessoas que pagam os impos-
tos) que projetos governamentais sejam bem gerenciados, afinal, espera-se que a
maioria dos usuários destes projetos seja o próprio cidadão.
Qual o objetivo da extensão governamental?

O propósito dessa extensão é melhorar a eficiência e efetividade do gerenciamento
de projetos governamentais.
Dado o tamanho do setor governamental, mesmo uma pequena melhoria terá be-
nefícios enormes para todos os envolvidos.

MELHORES PRÁTICAS PARA GESTÃO DE PROJETOS GOVERNAMENTAIS
APÊNDICE D 443
O que faz projetos governamentais serem únicos

Projetos do governo possuem duas características básicas:
São controlados pelos governos estaduais, federais e municipais.
Os fundos são provenientes de impostos e taxas obrigatórias.
Contém fases que são requeridas (obrigatórias) por leis (licitação).
Envolve stakeholders desconhecidos no setor privado, tais como líderes de opo-
sição, mídia e as gerações futuras.
Em relação aos processos e às práticas de gerenciamento de projetos, existem si-
milaridades entre os projetos do setor privado e projetos do governo. Das 300 práti-
cas descritas na extensão governamental, 75% não foram modificadas do PMBOK.
Aproximadamente 15% são novas e específicas da indústria governamental e 10%
foram modificadas (ou adaptadas) do PMBOK.
Projetos governamentais possuem normalmente três fases antes de sua execução:
Definição
Planejamento
Licitação
Vargas aponta algumas características quanto ao gerenciamento de projetos go-
vernamentais, conforme a seguir:
A cobrança da sociedade é de caráter mais subjetivo e geral.
Maior risco quanto à quebra da continuidade administrativa.
Freqüentemente ocorre paralisação de programas e projetos por falta de recur-
sos.
Maior dispersão quanto à tomada de decisão.
Pouca tradição no uso das ferramentas de planejamento e controle.
Baixo grau de consciência quanto à realidade da competição.
Presença marcante da burocracia.
Conceito de qualidade ainda incipiente.
Esferas do governo
As esferas do governo são três: Federal, Estadual e Municipal.
Federal: Quando a abrangência do projeto é nacional e controlado pela mais

alta cúpula do governo.
Estadual: Quando o projeto afeta uma região, especificamente um estado. Esta
esfera tem uma automonia maior e é controlada pelos governos estaduais (go-
vernador e assessores).
Municipal: Quando a abrangência do projeto é local, controlado pelas prefeitu-
ras das cidades.

Antes de iniciar um projeto do governo, o gerente de projeto deve ficar atento às

leis e aos impostos específicos que regem essas esferas, pois podem variar dependen-
do de sua abrangência.
Um exemplo de processo de gerenciamento de projetos da extensão

governamental
Para melhor entendimento da extensão governamental do PMBOK, o PMI determi-
nou três formatações no decorrer do texto para as entradas; ferramentas e técnicas; e
saídas do processos de gerenciamento de projetos.
Elementos que permanecem inalterados no PMBOK são mantidos em texto

sem formatação.
Novos itens (específicos da área de aplicação governamental) são impressos em
negrito e itálico.
Elementos alterados estão em itálico.
Veja na página a seguir um breve exemplo de como adaptar os processos do

PMBOK no gerenciamento de projetos do governo. Os termos foram mantidos em
inglês para evitar traduções errôneas dos termos, entretanto, uma breve descrição
do conceito de cada um é fornecida.
Annual budget cycle

Círculo anual de orçamento.
Split funding by Program

Alguns fundos são direcionados para programas específicos de projetos. Regras são
estabelecidas para o provimento de fundos para cada tipo de programa.
Matching funds
É uma forma de dividir os fundos por programa.
Split funding by fiscal year

Se um projeto começa em um ano fiscal e termina em outro, será necessário o provi-
mento de fundos do orçamento do ano fiscal no qual o projeto está sendo executado.
Obligations
Ajuda a direcionar as restrições do círculo anual de orçamento. São úteis em projetos
de grandes licitações. Os fundos podem ficar disponíveis por dois ou cinco anos, de-
pendendo das regras que são estabelecidas. Isso evita a necessidade de votação de no-
vos fundos em cada ano fiscal. São utilizadas às vezes entre os governos como transfe-
rências de pagamentos.

Counterpart funding
Envolve fundos do setor privado e é uma opção de “desenvolver” os países que não
têm fundos suficientes para custear toda infra-estrutura básica da população.
Resumo
Conforme estudamos neste capítulo, a extensão governamental do PMBOK oferece
práticas específicas e um apoio indispensável para o gerenciamento de projetos do
governo.
Percebemos por que a extensão governamental é necessária, constatamos qual o
objetivo da extensão governamental, verificamos o que faz projetos governamentais
serem únicos e vimos, na prática, um exemplo de processo de gerenciamento de
projetos adaptado na extensão governamental.
É interessante e altamente recomendável que gerentes de projetos envolvidos
com projetos governamentais saibam da existência dessa extensão, e, principalmen-
te, que tenham acesso às informações que constam em seu texto na íntegra.
Membros associados ao PMI Internacional podem fazer um download gratuito
dessa extensão (em arquivo .PDF). É necessário login e senha para fazer o download,
e estar em dia com a associação ao PMI, através do pagamento de uma taxa anual.
Aliás, este é um dos benefícios dos associados do PMI: poder fazer downloads gratui-
tos não somente dessa extensão, mas também de outras que o porventura o PMI dis-
ponibilize em seu site.
A Government Extension to A Guide to the Project Management Body of Knowledge pode
ser adquirida no site http://www.pmbookstore.org do Project Management Insti-
tute. Ao todo são 104 páginas de informações.
O gerente de projeto deve também ler, estudar e ter acesso à Lei 8.666, que esta-
belece normas gerais sobre licitações e contratos administrativos pertinentes a
obras, serviços, inclusive de publicidade, compras, alienações e locações no âmbito
dos Poderes da União, dos Estados, do Distrito Federal e dos Municípios. Essa Lei
pode ser acessada no site do Planalto no link: http://www.planalto.gov.br
Referências bibliográficas
A Guide To The Project Management Body Of Knowledge (Pmbok® Guide) – 2000 Edition. Newton Square:
Certified Associate In Project Management (Capmtm) Role Delineation Study. Newton Square:
CLELAND, Devid I. Project Management Casebook. Project Management Institute, 1998.
Construction Extension to a Guide To The Project Management Body of Knowledge. Project Mana-
gement Institute, 2003. Formato: CD.
Government Extension to A Guide to the Project Management Body of Knowledge. Newton Square: Project
Management Institute.
PENNYBACKER, James S. e LOWELL DYE, Eds. Project Portfolio Management. Center for Business
Practice, 1999.
People In Projects. Newton Square: Project Management Institute.

APÊNDICE D 447
PINTO, Jeffrey K. Power & Politcs in Project Management. Project Management Institute, 1996.
Practice Standard for Work Breakdown Structures. Project Management Institute, 2002.
Proceedings Of PMI Research Conference 2002. Newton Square: Project Management Institute, 2002.
Project Management Experience and Knowledge Self-Assessment Manual. Project Management
Institute, 2000.
Project Management Institute Practice Standard For Work Breakdown Structures. Newton Square:
Project Management Professional (PMP) Role Delineation Study. Newton Square: Project Manage-
Project Manager Competency Development Framework. Newton Square: Project Management
Institute, 1997.
Project Manager Competency Development Framework. Project Management Institute, 2002.
Q & As for the PMBOK Guide 2000 Edition. Project Management Institute, 2002.
The Future Of Project Management. Newton Square: Project Management Institute, 1998.
The Juggler´s Guide to Managing Multiple Projects. Project Management Institute, 1999.
The PMI Compendium of Project Management Practices. Project Management Institute, 2002.
The PMI Project Management Fact Book, Second Edition. Newton Square: Project Management
Institute, 1999.
The Project Sponsor Guide. Project Management Institute, 2002.
Artigos
As fontes dos artigos a seguir advêm da PM Network e do Project Management Journal,
ambos periódicos do PMI (Project Management Institute), publicados em língua in-
glesa.
Essas publicações são enviadas para todos os membros do PMI do Brasil e do mun-
do gratuitamente, mas também podem ser adquiridas como exemplares avulsos.
Maiores informações em http://www.pmi.org e http://www.pmbookstore.org
Alguns artigos possuem em seus títulos as palavras “gerenciamento de projetos
governamentais” explicitamente. Outros, apesar de não constarem tais palavras,
descrevem em seu conteúdo características e considerações importantes sobre o ge-
renciamento de projetos governamentais. Ao todo são 798 citações da palavra “go-
verno” (government) no conteúdo dos artigos.
760 Days and Counting … Will Your Organization Be Ready for the Year 2000? PM Network. Project
Management Institute. Dezembro, 1997.
A Consulting Engineer’s View. PM Network. Project Management Institute. Fevereiro, 1990.
A Decision Support System For Predicting Project Success. Project Management Journal. Project Ma-
nagement Institute. Setembro, 1992.
A Project Management View. PM Network. Project Management Institute. Fevereiro, 1990.
A Project Manager’s On-Ramp to the Information Superhighway. PM Network. Project Management
Institute. Outubro, 1996.
A Review of Cost/Schedule Control Systems Criteria Literature. Project Management Journal. Project
Management Institute. Setembro, 1994.
A Success Story. PM Network. Project Management Institute. Novembro, 1994.
Advantages and Disadvantages of E/C International Standards. Project Management Journal. Project

An Analysis Of Cost Overruns On Defense Acquisition Contracts. Project Management Journal. Pro-
ject Management Institute. Setembro, 1993.
An Architect’s View. PM Network. Project Management Institute. Fevereiro, 1990.
An Innovative Continuing Education/On-The-Job Training Program. PM Network. Project Manage-
ment Institute. Agosto, 1994.
Barriers to Project Partnering: Report from the Firing Line. Project Management Journal. Project Ma-
nagement Institute. Março, 1997.
Beyond Engineering. PM Network. Project Management Institute. Julho, 1992.
Building a Global Project Management Profession. PM Network. Project Management Institute. Ja-
neiro, 1997.
Building A New Russian Business Infrastructure: A New Frontier. PM Network. Project Management
Institute. Abril, 1993.
Caltrans’ Quest for “True Project Management” in Government Bureaucracy. Special Topics Issue:
PM in Government. Project Management Institute. Abril, 1997.
Causes of Project Failure: A Survey of Professional Engineers. PM Network. Project Management
Institute. Novembro, 1996.
Clothes … The Last Days of PMPeii. PM Network. Project Management Institute. Fevereiro, 1996.
Competition Strategies for Defense Projects. Project Management Journal. Project Management Insti-
tute. Março, 1995.
Complex Problem… Simple Concepts… Transformed Organization. PM Network. Project Manage-
ment Institute. Julho, 1996.
Decision Analysis in Projects: Utility and Multi-Criteria Decisions. PM Network. Project Manage-
ment Institute. Abril, 1995.
Defeating the Cost Plus Paradigm in Defense Projects. PM Network. Project Management Institute.
Maio, 1996.
Education And Training Of Program Management Personnel In DOD. PM Network. Project Manage-
ment Institute. Agosto, 1992.
Excellence In Cost, Schedule And Quality Performance: A Bold New Vision of Military Procure-
ment Policy. PM Network. Project Management Institute. Janeiro, 1992.
Expanding the Role of the Project Director as the CIO in the Information Technology Industry. Pro-
ject Management Journal. Project Management Institute. Setembro, 1996.
Exposure Draft – A Guide to the Project Management Body of Knowledge (PMBOKGuide) –
Appendix E – Application Area Extensions. PM Network. Project Management Institute. Novem-
bro, 1997.
Food Waste Composting at Larry’s Markets. PM Network. Project Management Institute. Fevereiro,
1995.
Four Challenges for Health Care Project Managers. PM Network. Project Management Institute. Ju-
lho, 1997.
From the Big Picture to Sub-projects: Project Management Lessons of Every Kind on the Supercon-
ducting Super Collider. PM Network. Project Management Institute. Novembro, 1990.
Governments and Project Management. Special Topics Issue:PM in Government. Project Manage-
Great Expectations: Turning Failure Into Success–And Vice Versa. PM Network. Project Manage-
ment Institute. Maio, 1997.
Hibernia Oil Production Platform. PM Network. Project Management Institute. Agosto, 1996.
How Do You Measure The Quality Of Your Project Management? PM Network. Project Management
Institute. Maio, 1993.
International Alliances In Construction. Project Management Journal. Project Management Institute.
Junho, 1993.

APÊNDICE D 449
International Competitiveness Of U.S. Construction Firms. Project Management Journal. Project Ma-
nagement Institute. Março, 1991.
International Conferences: More Important Than We Realize. PM Network. Project Management
Institute. Maio, 1997.
Issue Forth Those Findings. PM Network. Project Management Institute. Fevereiro, 1997.
It Takes A Regional Village: New Concept Takes Hold in the U.S. Army Corps of Engineers. Special
Topics Issue: PM in Government. PM Network. Project Management Institute. Abril, 1997.
Keys To Growing A Minority– Or Woman-Owned Business. PM Network. Project Management
Institute. Março, 1994.
Learning Project Management Outside The Classroom: The Internship. Project Management Journal.
Project Management Institute. Março, 1992.
Local Governments: A Cultural Perspective. PM Network. Project Management Institute. Agosto,
1994.
Making Affordable Housing Attainable Through Modern Project Management. PM Network. Project
Management Institute. Agosto, 1994.
NAFTA: Implications for Project Management. PM Network. Project Management Institute. No-
vembro, 1993.
New Military Procurement Policy: Commercial Off-the-Shelf (COTS). PM Network. Project Mana-
gement Institute. Janeiro, 1992.
Part II – Views Of The Professions. PM Network. Project Management Institute. Fevereiro, 1990.
Partnership Toward Improvement. Project Management Journal. Project Management Institute. Ju-
nho, 1995.
Perceptions On Partnering In The Public Sector. Project Management Journal. Project Management
Institute. Dezembro, 1992.
PM Under Rampant Inflation: Meeting Cost and Schedule Objectives in Brazil. PM Network. Project
Politics and Project Performance: The Fourth Dimension of Project Management. PM Network. Pro-
ject Management Institute. Julho, 1995.
Program Management: The Customer Focus. PM Network. Project Management Institute. Outubro,
1991.
Project Budgets are not funtional budgets. PM Network. Project Management Institute. Março, 1994.
Project Controls: How Much Is Enough? PM Network. Project Management Institute. Novembro,
1996.
Project Management in Globalizing Economies. Project Management Journal. Project Management
Project Management: The Next Generation. PM Network. Project Management Institute. Julho,
1993.
Proposal Management: Analyzing Business Opportunities. PM Network. Project Management Insti-
tute. Janeiro, 1996.
Reasons for Construction Business Failures in Saudi Arabia. Project Management Journal. Project Ma-
nagement Institute. Junho, 1997.
Redefining the Supplier/Vendor Role for Large, Long-Term Government Programs Avon C. Ja-
mes. PM Network. Project Management Institute. Abril, 1996.
Redeploying Hanford’s Metalworking Equipment. PM Network. Project Management Institute.
Março, 1995.
Re-Engineering An Integrated Project Management System Within At&T-Fsat. PM Network. Project
Management Institute. Agosto, 1993.
Reinventing Tank Waste Remediation System Project Management. PM Network. Project Manage-
ment Institute. Março, 1995.

Restructuring Government/Defense Contractors To Compete In The Commercial Marketplace.

PM Network. Project Management Institute. Maio, 1994.
Risk Assessment And Options In Project Finance. Project Management Journal. Project Management
RISKMAN: The New European Methodology for Project Risk Management. PM Network. Project
Management Institute. Novembro, 1993.
Sea-Land Service, Inc. PM Network. Project Management Institute. 1992.
Socio/Economic/Political Implications. PM Network. Project Management Institute. Fevereiro,
1990.
Some Reflections On Pert And Project Management. PM Network. Project Management Institute.
Maio, 1990.
Some Thoughts On C/Scsc And The Current State Of Project Management Tools. PM Network. Pro-
ject Management Institute. Outubro, 1993.
Soviet Joint Ventures: Pearls and Perils of Perestroika. PM Network. Project Management Institute.
Maio, 1991.
State Hospitals of Salzburg 2000. PM Network. Project Management Institute. Julho, 1997.
Successful Project Execution: A Model. Project Management Journal. Project Management Institute.
Dezembro, 1991.
Successful Utility Project Management From Lessons Learned. Project Management Journal. Project
Survival Of The Fittest? Doing Things Right. Doing the Right Things. PM Network. Project Manage-
ment Institute. Novembro, 1994.
Taking Step Four With Earned Value: Establish the Project Baseline. PM Network. Project Manage-
ment Institute. Maio, 1995.
Team Building and Project Management: How Are We Doing? Project Management Journal. Project
Team-Oriented Organizations Come In Various Shapes And Forms. PM Network. Project Manage-
ment Institute. Junho, 1994.
The “Earned Value” Concept: Back to the Basics. PM Network. Project Management Institute. Janei-
ro, 1994.
The “Earned Value” Concept: Taking Step Two-Plan and Schedule the Project. PM Network. Project
The Asian Elephant Forest. PM Network. Project Management Institute. Julho, 1990.
The Case for Earned Value. PM Network. Project Management Institute. Dezembro, 1996.
The Channel Tunnel: Creating a Modern Wonder-of-the-World. PM Network. Project Management
Institute. Julho, 1992.
The Development Project Cycle And A Barbadian Project. Project Management Journal. Project Mana-
gement Institute. Junho, 1991.
The Editor’s Perspective. PM Network. Project Management Institute. Maio, 1991.
“The Envelope, Please…” PM Network. Project Management Institute. Janeiro, 1997.
The F-22 Advanced Tactical Fighter: The Air Force Model Acquisition Program. PM Network. Pro-
ject Management Institute. Setembro, 1993.
The Great Communicator. PM Network. Project Management Institute. Fevereiro, 1995.
The Importance of Fundamentals. Project Management Journal. Project Management Institute. Junho,
1994.
The Importance of Fundamentals. PM Network. Project Management Institute. Junho, 1994.
The Milwaukee Water Pollution Abatement Program: Its Stakeholder Management. PM Network.
Project Management Institute. Abril, 1991.
The Rise and Fall of Project Management … The Emperor’s New

APÊNDICE D 451
The Status of the Project Management Profession in the Americas, Africa and the Middle East. PM
Network. Project Management Institute. Março, 1997.
The Top 10 Ways to Game the C/SCSC System, Part 1. PM Network. Project Management Institute.
Novembro, 1997.
The Tri-Cities: Achieving Economic Transition Through Environmental Remediation. PM Network.
Project Management Institute. Março, 1995.
Total Quality Management At Harris: Six Years Of Continuous Improvement. PM Network. Project
Management Institute. Julho, 1990.
Traditional PM and TQM: Inconsistent in Theory and Practice? PM Network. Project Management
Institute. Fevereiro, 1996.
Using Project Finance To Help Manage Project Risks. Project Management Journal. Project Manage-
ment Institute. Junho, 1991.
Using Project Management To Create An Entrepreneurial Environment In The Czech And Slovak
Republics. PM Network. Project Management Institute. Abril, 1993.
Why Become a Project Management Professional? PM Network. Project Management Institute. Ja-
neiro, 1993.
Web Sites
www.pmi.org – Site do Project Management Institute
www.planalto.gov.br – Site do Planalto. Lei 8.666 e outras.
br.yahoogroups.com/PMI-MG-SIGGov/ – Grupo de discussões sobre projetos governamentais es-
tabelecido em Belo Horizonte, MG. Moderador: Marconi Fábio Vieira, PMP.
Abaixo você encontra os links relacionados ao Governo brasileiro, divididos em:

Planalto, Poder Executivo, Poder Legislativo e Poder Judiciário.
Links do PLANALTO
O Presidente – http://www.planalto.gov.br/bio.htm
Advocacia-Geral da União – http://www.agu.gov.br/
Casa Civil – http://www.presidencia.gov.br/casacivil
Comissão de Ética Pública – http://www.planalto.gov.br/etica
Comunicação e Gestão Estratégica – http://www.planalto.gov.br/secom
Controladoria-Geral da União – http://www.planalto.gov.br/cgu/index.htm
Desenv. Econômico e Social – http://www.presidencia.gov.br/cdes
Secretaria-Geral – http://www.planalto.gov.br/secgeral
Segurança Alimentar e Combate à Fome – http://www.presidencia.gov.br/mesa
Segurança Institucional – http://www.planalto.gov.br/gsi
Links do PODER EXECUTIVO

Presidência
http://www.presidencia.gov.br/
Vice-presidência
http://www.vice-presidencia.gov.br/

Ministérios
http://www.agricultura.gov.br/
http://www.assistenciasocial.gov.br/
http://www.cidades.gov.br/
http://www.mct.gov.br/
http://www.mc.gov.br/
http://www.presidencia.gov.br/cgu
http://www.cultura.gov.br/
http://www.defesa.gov.br/
http://www.mda.gov.br/
http://www.mdic.gov.br/
http://www.mec.gov.br/
http://www.esporte.gov.br/
http://www.presidencia.gov.br/mesa
http://www.fazenda.gov.br/
http://www.integracao.gov.br/
http://www.mj.gov.br/
http://www.mma.gov.br/
http://www.mme.gov.br/
http://www.planejamento.gov.br/
http://www.mpas.gov.br/
http://www.mre.gov.br/
http://www.saude.gov.br/
http://www.mte.gov.br/
http://www.transportes.gov.br/
http://www.turismo.gov.br/
Secretarias de Estado
http://www.presidencia.gov.br/secgeral
http://www.presidencia.gov.br/secom
Especial de Aqüicultura e Pesca

http://www.presidencia.gov.br/cdes
http://www.presidencia.gov.br/sedh
Especial de Políticas para as Mulheres

http://www.senad.gov.br/
Orgãos Federais
http://www.agespacial.gov.br/
http://www.brasil.gov.br/orgaos/agencias.htm
http://www.ada.gov.br/
http://www.ana.gov.br/
http://www.aneel.gov.br/
http://www.anatel.gov.br/
http://www.antt.gov.br/
http://www.anp.gov.br/
http://www.ans.gov.br/

APÊNDICE D 453
http://www.anvisa.gov.br/
http://www.brasil.gov.br/orgaos/bancos.htm
http://www.bancoamazonia.com.br/
http://www.bancobrasil.com.br/
http://www.bcb.gov.br/
http://www.bndes.gov.br/
http://www.bnb.gov.br/
http://www.caixa.gov.br/
http://www.casadamoeda.com.br/
http://www.capes.gov.br/
http://www.cnpq.br/
http://www.conab.gov.br/
http://www.correios.com.br/
http://www.cvm.gov.br/
http://www.dac.gov.br/
http://www.datasus.gov.br/
http://denatran.serpro.gov.br/index2.htm%20
http://www.dnit.gov.br/
http://www.dnocs.gov.br/
http://www.dnpm.gov.br/
http://www.mre.gov.br/templ-homepagepostos.htm
http://www.embratur.gov.br/
http://www.esaf.fazenda.gov.br/
http://www.finep.gov.br/
http://www.fiocruz.br/
http://www.funai.gov.br/
http://www.funasa.gov.br/
http://www.geipot.gov.br/
http://www.ibama.gov.br/
http://www.ibge.gov.br/
http://www.ibict.br/
http://www.in.gov.br/
http://www.inmetro.gov.br/
http://www.inpi.gov.br/
http://www.int.gov.br/
http://www.iphan.gov.br/
http://www.ita.cta.br/
http://www.brasil.gov.br/orgaos/energia.htm
http://www.aneel.gov.br/
http://www.cgtee.gov.br/
http://www.eletrobras.gov.br/
http://www.eln.gov.br/
http://www.eletrosul.gov.br/
http://www.furnas.com.br/
http://www.itaipu.gov.br/
http://www.brasil.gov.br/orgaos/pesq.htm
http://www.cnpq.br/
http://www.cprm.gov.br/
http://www.embrapa.br/

http://www.finep.gov.br/
http://www.ibge.gov.br/
http://www.ibict.br/
http://www.inpa.gov.br/
http://www.ipea.gov.br/
http://www.rnp.br/
http://www.brasil.gov.br/orgaos/mineral.htm
http://www.cprm.gov.br/
http://www.dnpm.gov.br/
http://www.petrobras.com.br/
http://www.dpf.gov.br/
http://www.dprf.gov.br/
http://www.receita.fazenda.gov.br/
http://www.serpro.gov.br/
http://www.siapenet.gov.br/
http://www.sudene.gov.br/
http://www.susep.gov.br/
http://www.brasil.gov.br/orgaos/univ-fed.htm
http://www.ufac.br/
http://www.ufal.br/
http://www.unifap.br/
http://www.fua.br/
http://www.ufba.br/
http://www.unb.br/
http://www.ufc.br/
http://www.ufes.br/
http://www.uff.br/
http://www.ufg.br/
http://www.efei.br/
http://www.ufjf.br/
http://www.ufla.br/
http://www.ufma.br/
http://www.ufmt.br/
http://www.ufms.br/
http://www.ufmg.br/
http://www.ufmg.br/
http://www.ufop.br/
http://www.ufpa.br/
http://www.ufpb.br/
http://www.ufpr.br/
http://www.ufpe.br/
http://www.ufpel.tche.br/
http://www.ufpi.br/
http://www.unirio.br/
http://www.ufrj.br/
http://www.furg.br/
http://www.ufrn.br/
http://www.ufrgs.br/
http://www.unir.br/

APÊNDICE D 455
http://www.ufrr.br/
http://www.ufsc.br/
http://www.ufsm.br/
http://www.ufscar.br/
http://www.funrei.br/
http://www.ufs.br/
http://www.unitins.br/
http://www.ufu.br/
http://www.ufv.br/
http://www.unifesp.br/
Links do PODER LEGISLATIVO

Senado
http://www.senado.gov.br/
Câmara
http://www.camara.gov.br/
Tribunais de Contas
Estaduais
http://www.tce.ms.gov.br/
http://www.tce.mt.gov.br/
http://www.tce.pr.gov.br/
http://www.tce.go.gov.br/
http://www.tce.pe.gov.br/
http://www.tce.pb.gov.br/
http://www.vix.nutecnet.com.br/tcees/
http://www.tcm.ce.gov.br/
http://www.tc.al.gov.br/
http://www.tce.rj.gov.br/
http://www.tc.df.gov.br/
http://www.tce.pi.gov.br/
http://www.tce.sc.gov.br/
http://www.tce.rr.gov.br/
http://www.tce.ro.gov.br/
http://www.tce.ma.gov.br/
http://www.tce.to.gov.br/
http://www.tce.se.gov.br/
http://www.tce.sp.gov.br/
http://www.tce.ba.gov.br/
http://www.tce.am.gov.br/
http://www.tce.rs.gov.br/
http://www.tce.rn.gov.br/
http://www.tce.mg.gov.br/

Federal
http://www.tcu.gov.br/
Municipais
http://www.tcm.ba.gov.br/
http://www.tcm.go.gov.br/
http://www.tcm.sp.gov.br/
http://www.tcm.ce.gov.br/
http://www.tcm.rj.gov.br/
Links do PODER JUDICIÁRIO

Supremos
Supremo Tribunal Militar
http://www.stm.gov.br/
Supremo Tribunal Federal

http://www.stf.gov.br/
Supremo Tribunal de Justiça

http://www.stj.gov.br/
Tribunais do Trabalho
Superior do Trabalho
http://www.tst.gov.br/
http://www.tst.gov.br/
Estaduais
http://www.trtrio.gov.br/
http://www.trt02.gov.br/
http://www.mg.trt.gov.br/
http://www.trt13.gov.br/body.htm

APÊNDICE D 457
Tribunais Eleitorais
Superior Eleitoral
http://www.tse.gov.br/
Estaduais
http://www.tre-ac.gov.br/
http://www.tre-al.gov.br/
http://www.tre-ap.gov.br/
http://www.tre-am.gov.br/
http://www.tre-ba.gov.br/
http://www.tre-ce.gov.br/
http://www.tre-df.gov.br/
http://www.tre-es.gov.br/
http://www.tre-go.gov.br/
http://www.tre-ma.gov.br/
http://www.tre-mt.gov.br/
http://www.tre-ms.gov.br/
http://www.tre-mg.gov.br/
http://www.tre-pa.gov.br/
http://www.tre-pb.gov.br/
http://www.tre-pr.gov.br/
http://www.tre.pe.gov.br/
http://www.tre-pi.gov.br/
http://www.tre-rj.gov.br/
http://www.tre-rn.gov.br/
http://www.tre-rs.gov.br/
http://www.tre-ro.gov.br/
http://www.tre-rr.gov.br/
http://www.tre-sc.gov.br/
http://www.tre-sp.gov.br/
http://www.tre-se.gov.br/
http://www.tre-to.gov.br/
Tribunais de Justiça
http://www.geocities.com/Athens/9227/
http://www.ez-bh.com.br/tamg
http://www.brasnet-online.com.br/tjap/welcome.html
http://www.netium.com.br/tjam/index.htm
http://www.tj.ba.gov.br/
http://www.tj.es.gov.br/
http://www.tj.ce.gov.br/

http://www.tjdf.gov.br/
http://www.tj.mt.gov.br/
http://www.tj.ms.gov.br/
http://www.tj.pb.gov.br/
http://www.tj.pa.gov.br/
http://www.celepar.br/tjpr/index.html
http://www.elogica.com.br/tjpe/
http://www.tj.rj.gov.br/
http://www.tj.rs.gov.br/
http://www.tj.ro.gov.br/
http://www.tj.rr.gov.br/
http://www.tj.sc.gov.br/
http://www.tj.sp.gov.br/
http://www.tj.se.gov.br/
http://www.tj.pi.gov.br/
http://www.tjm.mg.gov.br/

APÊN D ICE E
Artigos traduzidos sobre

gerenciamento de riscos
Este Apêndice fornece oito artigos de gerenciamento de riscos que traduzi volunta-
riamente para as pessoas interessadas e profissionais da área de GP. Sou responsável
pela tradução oficial dos artigos do Risk Doctor para a língua portuguesa (Brasil e Por-
tugal).
São artigos de autoria do Dr. David Hillson, consultor internacional, instrutor e
autor de livros na área de gestão de riscos. A publicação desses artigos foi autorizada
pelo próprio Dr. David Hillson. Maiores informações sobre ele, seus livros e servi-
ços podem ser obtidas no site http://www.risk-doctor.com
No CD que acompanha este livro, na pasta Artigos você encontrará todos os arti-
gos em inglês e os artigos já traduzidos para o português publicados até o mês de ju-
nho de 2006. A cada mês o Dr. David Hillson publica um artigo em inglês abordando
um novo tema e suas respectivas versões traduzidas para o português, espanhol, ale-
mão, francês e chinês. Visite constantemente o site: http://www.risk-doctor.com/brie-
fings.htm para conferir os novos artigos.
Você poderá receber gratuita e mensalmente os próximos artigos de gerencia-
mento de riscos preenchendo o formulário no link: http://www.risk-doctor.com/subs-
cribe.htm.
Ao final deste Apêndice você encontrará um breve currículo (em inglês) do Dr.
David Hillson.

Decisões, decisões
© Novembro 2005, Dr David Hillson PMP FAPM
david@risk-doctor.com
“O futuro é um outro país, eles fazem coisas diferentes lá”, para citar as palavras de
abertura do romance de L. P. Hartley, The Go Between (O Mensageiro). Uma grande
parte do processo de gestão de riscos envolve olhar para o futuro e tentar entender o
que poderá acontecer e se será relevante. Uma importante técnica quantitativa que
pode ser útil é a análise da árvore de decisão. Ela tem sido negligenciada nos últimos
anos, mas agora está experimentando um ressurgimento. Algumas pessoas acredi-
tam que ela deve ser reservada para decisões estratégicas, e outras consideram a téc-
nica complexa e difícil. Mas de fato ela é realmente simples, e pode ser aplicada em
muitas situações onde haja incerteza.
O método da árvore de decisão reconhece que existem dois fatores importantes

que afetam o futuro – escolha e probabilidade. E ao avaliá-los teremos que conside-
rar dois parâmetros – custos e conseqüências. Esses quatro elementos formam a base
de análise de árvore de decisão.
O primeiro passo ao construir uma árvore de decisão é identificar as opções que

temos que escolher para alcançarmos nossos objetivos. Essas escolhas formam
os nós de decisão da árvore. Por exemplo, “fabricar ou comprar”, “fazer dentro
da empresa ou fora”, “pela via rápida ou tradicional”, “método inovador ou de
eficácia comprovada”, “distribuidor A ou B”, “de alta ou baixa prioridade”.
Cada uma dessas decisões leva a diferentes resultados, que são refletidos na ár-
vore de decisão usando outros três elementos.
O fator mais simples associado às escolhas alternativas é o custo, incluindo custo
de implementação e de oportunidade. Em alguns casos isso pode ser negativo,
refletindo uma economia. Mas é importante aceitar que sempre existe um cus-
to associado ao fazermos uma escolha, e uma estimativa disso deve ser incluída
em cada nó da árvore de decisão.
A probabilidade é também uma variável importante associada às opções de deci-
sões diferentes. Cada alternativa poderia ter uma gama de resultados possíveis,
embora algumas escolhas possam conduzir a um único resultado. Por exemplo,
diferentes opções de tecnologia podem ter possibilidades diferentes de sucesso
ou fornecedores diferentes podem ser mais ou menos dignos de confiança.
Onde há incerteza sobre o resultado de uma decisão, há também a necessidade
de se identificar e avaliar a probabilidade estimada de cada resultado. E alguns
eventos de probabilidade podem também gerar a possibilidade de novas esco-
lhas, produzindo uma série de ramificações de nós dentro da árvore.

ARTIGOS TRADUZIDOS SOBRE GERENCIAMENTO DE RISCOS
APÊNDICE E 461
Por último, a árvore de decisão deve exibir as conseqüências. Se alguma opção de

decisão em particular está prestes a ser tomada, incorrendo custos e riscos, o
resultado final deve ser estimado, o que normalmente é o desfecho de imple-
mentar essa decisão. Tipicamente isso se expressa em termos financeiros, em-
bora outras medidas possam ser utilizadas. A estrutura da árvore de decisão
descreve o resultado previsto de cada combinação de escolha/probabilidade,
representando os níveis ao extremo de cada nó.
Ao construir uma árvore de decisão com estes quatro componentes, é possível fa-
zermos uma análise para determinar a escolha mais favorável, levando em considera-
ção custos, probabilidades e conseqüências associados. Primeiramente, devemos seguir
pela árvore de decisão em cada caminho lógico alternativo e o seu valor se calcula
acumulando custos e benefícios do começo ao fim. Então, utilizando estes valores e
verificando o retorno de cada caminho lógico alternativo, o “valor esperado” de cada
escolha é calculado, levando em conta as conseqüências quando as probabilidades
ocorrerem. O nó que contiver o valor esperado mais alto será a opção de decisão re-
comendada.
Existem vários desafios de utilizar as árvores de decisão de maneira eficaz, incluin-
do a limitação prática do método de analisar um número pequeno de opções de deci-
são com uma gama limitada de riscos possíveis. O projeto típico envolve muitas deci-
sões em níveis diferentes, cada uma com uma ampla gama de riscos associados; e ten-
tar demonstrar isso somente em uma árvore de decisão pode resultar em um modelo
enorme e sem utilidade. A técnica requer também que todos os fatores sejam repre-
sentados de forma quantitativa – custos e conseqüências se expressam normalmente
em termos financeiros, e a probabilidade deve ser estimada para todas as possibilida-
des. E a árvore de decisão supõe também a existência de “uma pessoa que toma deci-
são neutra aos riscos”, cujas escolhas se baseiam em valor esperado mais alto – o que
acontece raramente.
Apesar dessas limitações, a análise da árvore de decisão apresenta uma técnica
quantitativa poderosa para avaliar futuros possíveis, levando em consideração os
efeitos tanto da escolha como da probabilidade e estimando ambos custos e conse-
qüências.
Gestão de Riscos Pessoal

© Janeiro 2006, Dr. David Hillson PMP FAPM
Uma definição comum de risco é “um evento ou condição incerta que se ocorrer,
terá um efeito sobre pelo menos um objetivo”. Essa definição genérica nos permite
aplicar a gestão de riscos para uma grande gama de atividades, onde quer que possa-
mos definir objetivos distintos. Isso inclui a gestão de riscos pessoal, identificando e ge-
renciando as incertezas que podem afetar a conquista dos nossos objetivos pessoais.

Como em qualquer outra área de aplicação, a gestão de riscos pessoal pode ser
aplicada em diferentes níveis de detalhe. O segredo está na habilidade de especificar
bem os nossos objetivos pessoais. Em um nível mais alto podemos dizer que o nosso obje-
tivo é ser “feliz, saudável, estar em forma e ser sábio” e podemos identificar e geren-
ciar os riscos pessoais estratégicos que podem afetar esses objetivos principais. Isso
requer a abordagem de assuntos mais amplos como nossos relacionamentos pessoais,
dieta e regime de exercícios, ou investimentos e planos de pensões.
Ou podemos identificar objetivos pessoais mais específicos do tipo “reduzir meu
peso em nove quilos até o final de junho”, ou “aprender a falar fluentemente uma lín-
gua estrangeira antes das minhas férias de verão” ou “obter uma promoção em doze
meses”. Para cada um desses objetivos específicos podemos então aplicar os proces-
sos de gestão de riscos para nos ajudar a alcançá-los.
O processo é exatamente o mesmo como qualquer outra área de aplicação de gestão
de riscos. Depois de definir os objetivos, o próximo passo é identificar os riscos, incluindo
tanto as ameaças que podem nos atrapalhar como as oportunidades que podem nos aju-
dar. Para um objetivo de desenvolvimento de carreira, por exemplo, os riscos negati-
vos poderiam incluir o seguinte: eu poderia ser designado a uma nova função que ab-
sorva todo o meu tempo e energia; eu poderia investir em uma formação que não for-
neça as técnicas ou conhecimentos necessários; eu poderia ter expectativas irrealistas e
desistir. No lado positivo, uma nova oportunidade pode surgir no trabalho ou em ou-
tro lugar; eu seria capaz de utilizar habilidades completamente diferentes para mudar
de área; eu poderia encontrar alguém que me oferecesse meu próximo trabalho ideal.
Após a identificação dos riscos, vem a análise qualitativa e quantitativa, estimando a
probabilidade e o impacto de cada risco identificado para priorizá-los para ações fu-
turas. Escalas simples com “alto/médio/baixo” podem ser usadas para este propósi-
to, permitindo encontrar as piores ameaças e as melhores oportunidades.
Isso precisa ser seguido de um plano de respostas a riscos, encontrando as ações eficazes
e apropriadas para minimizar as ameaças e maximizar as oportunidades. Algumas des-
sas ações podem ser simples (conversar com o chefe ou colegas sobre possíveis oportu-
nidades internas, procurar cursos de formações disponíveis) e outras podem exigir um
esforço e investimentos maiores (obter coaching para explorar melhor meus objetivos
pessoais, juntar-se a uma associação profissional para melhorar meu networking).
Finalmente, as respostas identificadas precisam ser implementadas e seus efeitos
devem ser monitorados, para verificar se estão nos conduzindo em direção aos nossos
objetivos. Onde for necessário, devemos desenvolver novas respostas, permanecen-
do em alerta à possibilidade de riscos secundários. E nossa análise qualitativa e quan-
titativa de riscos deve ser atualizada com freqüência para encontrarmos e responder-
mos as novas ameaças e oportunidades.
O começo de um Ano Novo pode ser um bom momento para aplicarmos a ges-
tão de riscos pessoais, revendo onde estamos atualmente em relação onde quere-
mos estar ou chegar, e desenvolver estratégias e ações para mudar onde for neces-

APÊNDICE E 463
sário. A gestão de riscos não é aplicada somente no trabalho ou para o mundo dos
negócios – ela pode nos ajudar também a conquistar nossos objetivos pessoais.
Tente aplicar os processos de riscos para sua vida pessoal e você perceberá que di-
ferença isso pode fazer.
Gestão de Oportunidades Significa Aumento de Escopo?

© Fevereiro 2006, Dr. David Hillson PMP FAPM
Para muitas pessoas a idéia de utilização dos processos de riscos para identificar e
gerenciar as oportunidades é nova, já que o foco estabelecido por elas está em lidar
com as ameaças. E, por isso, as pessoas sentem certa dificuldade para encontrar as
oportunidades. Um ponto preocupante é que a busca proativa por oportunidades
pode resultar em aumento de escopo, como resultado da procura por benefícios ex-
tras não planejados em complemento àqueles já definidos no escopo acordado. Per-
seguir esses benefícios extras pode desviar a atenção e os esforços dos objetivos origi-
nais e ser pouco produtivo.
Um colega ilustrou o cenário anterior quando determinou para si mesmo um objeti-
vo de perder um pouco de peso e decidiu começar a correr. Ele percebeu que realmen-
te se divertia enquanto corria, que poderia até ser um talentoso corredor e que talvez
fosse capaz de se associar a um clube ou participar de uma maratona. Mas para essas
percepções tornarem-se oportunidades, ele deveria explorá-las de forma proativa?
Elas não têm nada a ver diretamente com o objetivo original de perder peso. Elas não
seriam apenas classificadas como escopo adicional ao projeto de perder peso?
A mesma situação pode acontecer no trabalho. Se, na tentativa de melhorar um
produto existente descobrimos uma brecha no mercado para criar um novo produ-
to, nós nos deparamos com uma oportunidade genuína a ser perseguida ou somente
com um potencial aumento de escopo? A resposta para essa importante questão é
tratar as oportunidades da mesma maneira que as ameaças. Então, o que aconteceria
se durante a avaliação de riscos do projeto identificássemos uma ameaça em que o
impacto negativo potencial estaria fora do escopo do projeto? Iríamos nos responsa-
bilizar por endereçar essa ameaça no nosso projeto, desde que constatássemos a pos-
sibilidade de gerenciá-la? O fato é que uma ameaça fora do escopo deve ser escalada
para alguém fora do projeto que tenha poder de decisão, talvez o patrocinador do
projeto ou para outra pessoa num outro departamento da empresa.
Da mesma forma, se nós identificarmos uma oportunidade que está fora das fron-
teiras da nossa responsabilidade, não poderíamos apenas decidir incluí-la no nosso
projeto. Em vez disso, devemos escalar as oportunidades fora do escopo para alguém
que será capaz de decidir se e como devemos conduzi-la.
A chave para tomar uma decisão entre escalar um risco ou lidar com ele nós mes-
mos é lembrar que as ameaças e as oportunidades devem ser definidas em relação aos
objetivos. Então, os únicos riscos que devem ser gerenciados através dos processos

de riscos do projeto são aqueles que podem afetar os objetivos do projeto. Qualquer
ameaça ou oportunidade em que o impacto potencial está fora dos objetivos acorda-
dos do projeto deve ser escalada. Isso garantirá que esses tipos de riscos não resulta-
rão automaticamente em aumento de escopo, embora, é claro, uma decisão de cará-
ter prático possa ser tomada para mudar o escopo para incluir uma boa e nova opor-
tunidade em particular ou evitar uma ameaça séria e ainda maior.
Em vez de se preocupar com o aumento de escopo, a busca por oportunidades
deve considerar quaisquer aspectos que nos ajudem a alcançar os objetivos acorda-
dos. Nós estamos procurando por formas de trabalhar “melhor, mas rápido e mais
barato” dentro do escopo existente, e não de tentar aumentar o escopo. Meu colega
precisa encontrar maneiras criativas de se ajudar a perder peso mais rápido com me-
nos esforço, e não se preocupar em correr uma maratona – a não ser que ele queira
iniciar um novo projeto com um objetivo diferente.
Chance Zero de um Projeto Zero-Risco

© Março 2006, Dr. David Hillson PMP FAPM
A palavra “risco” é comum e amplamente utilizada como parte do nosso vocabulá-
rio diário, relacionando-se a circunstâncias pessoais (saúde, pensões, seguros, inves-
timentos etc.), sociais (terrorismo, desempenho econômico, alimentação segura
etc.), e de negócios (governança corporativa, estratégia, continuidade do negócio
etc.). Gerenciamento de projetos é uma área em que a gestão de riscos encontrou
uma proeminente aplicação, talvez devido à natureza arriscada dos projetos.
Então, por que os projetos são tão arriscados? Existem algumas características que
são encontradas em todos os projetos e que os fazem ser naturalmente arriscados, in-
cluindo:
Único, envolve pelo menos alguns elementos que nunca foram feitos anterior-
mente.
Complexidade de vários aspectos, incluindo técnico, comercial e interfaces ou
relacional.
Premissas e restrições sobre o futuro, ambos explícitas (abertas) e implícitas (ocul-
tas), as quais podem ser equivocadas.
Objetivos, definindo os indicadores pelos quais o sucesso do projeto será deter-
minado: são geralmente fixados e algumas vezes conflitantes.
Pessoas, incluindo os membros da equipe do projeto e a alta gerência, clientes,
fornecedores e subcontratados, todos eles são imprevisíveis em algum aspecto.
Requisitos, expectativas e objetivos dos envolvidos, que podem variar, sobrepor-se
e podem ser conflitantes.
Mudança, já que todo projeto é um agente de mudança, movendo-se de um pre-
sente conhecido para um futuro desconhecido.

APÊNDICE E 465
Ambiente no qual o projeto existe, incluindo o ambiente organizacional interno

e o externo onde, as mudanças fora do controle do projeto podem ocorrer.
Essas características arriscadas são inerentes à natureza de todos os projetos e não

podem ser removidas sem mudar o projeto. Por exemplo, um “projeto” que não é
único, não tem restrições nem pessoas envolvidas e não introduz uma mudança não
pode ser considerado um projeto. Tentar remover os elementos arriscados de um
projeto iria transformá-lo em outra coisa, menos num projeto. Na verdade, os pro-
jetos são empreendidos para obter benefícios, correndo os respectivos riscos de uma
maneira controlada. É impossível imaginar um projeto sem riscos.
É claro que alguns projetos possuem riscos mais altos, enquanto outros menores,
mas todos os projetos são, por definição, arriscados em algum aspecto. O projeto
“zero-risco” é uma fábula – simplesmente não existe. Esse é o motivo pelo qual a ges-
tão de riscos é tão importante para um gerenciamento de projetos eficaz: já que to-
dos os projetos são expostos aos riscos, projetos bem-sucedidos são aqueles em que
os riscos são bem gerenciados.
Utilizando Metalinguagem para Desenvolver Respostas

© Maio 2006, Dr. David Hillson PMP FAPM
Para entendermos completamente um risco, é importante identificarmos suas
causas e também seus efeitos. A metalinguagem do risco pode ajudar separando cau-
sa-risco-efeito em uma descrição de três partes, tais como “Por causa de <uma ou mais
causas>, o <risco> pode ocorrer, conduzindo a <um ou mais efeitos>”. Esta des-
crição estruturada não somente garante uma definição clara do risco, como também
pode ser útil no desenvolvimento de respostas.
Existem quatro tipos básicos de respostas aos riscos:
1. Respostas agressivas, servido tanto para evitar uma ameaça, tornando-a im-
possível, como para explorar uma oportunidade, fazendo-a acontecer defini-
tivamente.
2. Envolvendo uma terceira pessoa para gerenciar o risco, tanto para transferir
uma ameaça como para compartilhar a oportunidade.
3. Mudando o tamanho de um risco, atrelando a probabilidade e/ou o impacto
para reduzir a ameaça e aumentar a oportunidade.
4. Correr riscos residuais que não podem ser gerenciados proativamente ou
que não podem ter os custos gerenciados de forma eficaz, aceitando uma
ameaça ou uma oportunidade.
Cada uma dessas estratégias pode ser “linkada” com a estrutura causa-risco-efeito. Pa-
ra as ameaças (por exemplo, riscos com impactos negativos) considera-se o seguinte:

Para evitar, remova ou mude a causa, ou quebre o link causa-risco-efeito de tal

maneira que a ameaça não seja mais possível. Por exemplo, riscos que aumen-
tam devido à falta de experiência podem ser evitados através da terceirização ou
de parceria. A taxa de câmbio do risco pode ser removida utilizando somente a
moeda local.
A transferência atrela o próprio risco, envolvendo outros no seu gerenciamen-
to, embora isso não mude o risco diretamente. Fazer um seguro é um exemplo
clássico de transferência de ameaça, embora cláusulas contratuais também pos-
sam ser usadas.
A mitigação objetiva enfraquecer o link causa-risco, ou minimiza o impacto ne-
gativo endereçando o link risco-efeito. Por exemplo, sabendo que o uso de um
fornecedor novo cria o risco de requisitos mal compreendidos, workshops de
familiarização podem ser promovidos para evitar tais situações.
A aceitação foca no efeito, reconhecendo que algumas ameaças não são controla-
das e podem acontecer. Essa estratégia pode simplesmente envolver lançar
mão dos fundos de contingência para se recuperar dos impactos negativos, ou
poderia envolver o desenvolvimento de um plano de reserva específico para ser
implementado se nós não tivermos sorte e a ameaça acontecer.
O mesmo pensamento se aplica para as oportunidades (por exemplo, riscos com
impactos positivos):
Explorar a oportunidade influenciando sua causa de tal forma que a oportunida-
de seja realizada. Por exemplo, uma decisão positiva pode ser tomada para in-
cluir um item opcional no escopo do projeto para criar um benefício adicional.
Compartilhar uma oportunidade endereça a parte do risco do elo causa-risco-efeito,
envolvendo outras pessoas no gerenciamento da oportunidade, talvez através de
uma parceria de risco-compartilhado ou contrato com incentivo.
Aumentar requer reforçar o link causa-risco para melhorar a probabilidade de uma
oportunidade acorrer ou reforçar o link risco-efeito para maximizar seu impacto
positivo. Se participar de um evento comercial cria oportunidades para novos ne-
gócios, a ação pode ser tomada para maximizar a visibilidade e atrair contratos.
Aceitando-se que uma oportunidade não pode ser influenciada proativamente
significa que a atenção está focada no seu efeito. Fundos de contingência podem
ser alocados para tirar vantagem dos impactos positivos ou um plano de reserva
poderia ser desenvolvido para uso, se nós tivermos sorte e a oportunidade para
fazê-lo acontecer.
O valor da metalinguagem do risco na identificação dos riscos já é bem conhecido.

Agora a mesma técnica pode fornecer um framework para o desenvolvimento de
respostas apropriadas para ameaças e oportunidades, garantindo que as ações pro-
movam de forma eficaz os resultados esperados.

APÊNDICE E 467
Análise das Necessidades de Informações de Riscoss dos Stakeholders

© Junho 2006, Dr. David Hillson PMP FAPM
Albert Einstein disse: “O maior problema da comunicação é a ilusão de que ela
ocorreu”. Comunicação é o elemento-chave da gestão de riscos, mas é geralmente
uma área fraca em termos de habilidades pessoais e estruturas organizacionais. Se
ninguém conhece os resultados dos processos de risco, nada poderá ser feito para ge-
renciar o risco. É comum o Registro de Riscos ser distribuído para todo mundo, mas
nem todo mundo precisa desse nível de informação.
Uma análise das necessidades de informações de riscos dos stakeholders pode aju-
dar a garantir que as saídas dos processos de risco sejam comunicadas de maneira es-
pecífica e precisa, de tal forma que cada stakeholder obtenha o que realmente preci-
sa, quando e como eles necessitam das informações. Isso começa com dois passos
bem simples:
1. Identificar todos os stakeholders, incluindo seus “bifes” ou interesses, nível

de comprometimento e grau de influência.
2. Para cada stakeholder, defina o tipo e o nível de informação de risco de que
ele necessita, o propósito para cada necessidade, o tempo necessário e a fre-
qüência da comunicação, e seu meio preferido ou formato de entrega.
Uma gama de saídas dos processos de risco deve então ser elaborada, com as se-
guintes considerações:
Conteúdo. Várias saídas de riscos podem ser produzidas em níveis diferentes de
detalhes, elaboradas de maneira hierárquica, de tal forma que as saídas de alto
nível possam ser produzidas como sumários de relatórios mais detalhados, para
evitar excesso de produção de múltiplas saídas.
Método de entrega. Alternativas podem incluir relatórios escritos em capa
dura ou em formato eletrônico (e-mail, intranet, Web site, banco de dados),
relatórios verbais (briefings, apresentações, reuniões de progresso), gráficos
ou saídas numéricas (tabelas, gráficos, pôsteres) etc.
Responsabilidades. Cada saída necessita de uma pessoa responsável pela sua
produção e de uma autoridade de aprovação. Isso pode também ser útil para
identificar aquelas contribuições que são necessárias, e quem receberá a saída
da informação. Um gráfico RACI (Responsável, Aprovação, Contribuinte,
Informado) pode se útil para defini-las e documentá-las.
As várias saídas dos processos de risco devem então ser mapeadas para as necessi-
dades de informações dos stakeholders, para garantir que todas as necessidades pos-
sam ser atendidas pelas saídas planejadas. Com isso é possível decidir quais saídas se-
rão necessárias para os respectivos stakeholders. Alguns stakeholders podem solici-

tar somente uma cópia do Registro de Riscos atual, ou um trecho relevante de infor-
mação do mesmo. Outros podem solicitar o Registro de Riscos mais uma narrativa
explanatória, ou um relatório completo de riscos. Um relatório resumo pode ser o
suficiente para outros stakeholders que não necessitam de informações detalhadas.
Em alguns casos uma simples saída de gráfico ou um painel pode ser apropriado.
Os stakeholders possuem necessidades diferentes de informações relacionadas ao
risco, e os processos de risco devem reconhecê-las e entregar as informações consis-
tentes no tempo certo e em um nível adequado de detalhe para atender às necessida-
des de cada stakeholder. Quando todos os stakeholders obtiverem as informações
necessárias dos processos de riscos, eles serão capazes de exercer seus papéis para ga-
rantir que o risco será gerenciado de forma eficaz.
Encorajando o envolvimento da equipe

© Julho 2006, Dr. David Hillson PMP FAPM
Prezado Risk Doctor,
Estou convencido de que uma abordagem estruturada de gestão de riscos ajudaria
no meu projeto, mas minha equipe está resistindo à idéia. Eles dizem que estão mui-
to ocupados para realizar a gestão de riscos além das tarefas normais do projeto. O
que você aconselharia?
Gerente de Projeto Frustado.
Prezado Gerente de Projeto Frustrado,

Qualquer um que esteja muito ocupado para gestão de riscos está muito ocupado!
Pessoas que não têm nenhum tempo para pensar com antecedência sobre os poten-
ciais problemas, sempre conseguem arranjar tempo para resolver os problemas
quando eles acontecem. Tente uma combinação dos oito passos seguintes para enco-
rajar a sua equipe na adoção da gestão de riscos:
1. Ordene. Se você pode, insista que um processo de gestão de riscos estrutura-

do deve ser implementado no seu projeto. Mesmo não sendo a resposta
completa, isso orientará as pessoas no que fazer. Se os procedimentos da sua
empresa incluem os processos de riscos, então você poderá referi-los e ex-
plicar que realmente eles não têm outra escolha.
2. Simplifique. A gestão de riscos não precisa ser complicada. Torne o processo
o mais simples possível sem comprometer a eficácia. Minimize a sobrecarga
da equipe, mantenha as reuniões de riscos curtas e não perca o foco, e so-
mente colete as informações que você pretende utilizar.
3. Normalize. Explique para a sua equipe que a gestão de riscos é uma “tarefa
normal do projeto” e que ela não é uma tarefa extra-opcional. Todos os pro-
jetos são arriscados, e a gestão de riscos precisa estar embutida em cada par-

APÊNDICE E 469
te do projeto. Planeje e reveja as respostas aos riscos, da mesma maneira que

as outras tarefas do projeto, e espere que sua equipe trate-as da mesma for-
ma que as outras tarefas.
4. Demonstre. O gerente do projeto deve liderar pelo exemplo, e ser um mode-
lo de atuação para a equipe. Se você mostrar que trata seriamente a identifi-
cação e a gestão de riscos, e você mesmo a realizar ativamente, a equipe se
sentirá mais confortável para seguir o seu exemplo.
5. Use. Quando relatórios de riscos são escritos e esquecidos, a equipe aprende
que a gestão de riscos não é importante. Mas onde a direção e a estratégia do
projeto são ajustadas sob a luz da gestão de riscos, as pessoas vêem que seus
esforços fazem a diferença no decorrer da execução do projeto.
6. Atualize. Se o Registro de Riscos for produzido uma vez e nunca for atualiza-
do, ou as respostas acordadas não forem revisadas e monitoradas, a avaliação
de riscos ficará desatualizada rapidamente e não será mais útil. Garanta que a
exposição atual de riscos é compreendida enfatizando a importância dos
processos de riscos.
7. Celebre. Procure provar que a gestão de riscos tratou uma ameaça de tal for-
ma que um problema foi evitado, ou a evidência de uma oportunidade po-
tencial foi convertida em uma vantagem real. Registre esses sucessos e fale
com as pessoas sobre eles. Sucesso gera sucesso.
8. “Influencie”. Procure apoio e venda a idéia para os gestores seniores. Quando
o chefe solicitar informações de riscos como parte da governança do proje-
to, a equipe saberá que isso é importante.
Estes passos devem garantir que sua equipe constate quão importante é a sua visão
de gestão de riscos e deve encorajá-la a levar isso a sério e a realizar por ela mesma a
gestão de riscos – porque isso funciona!
Cordialmente,
The Risk Doctor
Gerenciando a sorte
© Agosto 2006, Dr. David Hillson PMP FAPM
Prezado Risk Doctor,
Percebo que às vezes você deseja “boa sorte” para as pessoas. Por quê? Não é anti-
profissional para praticantes da gestão de riscos contarem com a sorte? Em vez disso
não deveríamos gerenciar os riscos? Por favor, explique.
Cordialmente,
Praticante da Gestão de Riscos Confuso

Prezado Praticante da Gestão de Riscos Confuso,

Vamos começar com uma definição: Sorte é “a força que determina ou regula tudo o
que ocorre, e cuja causa se atribui ao acaso das circunstâncias ou a uma suposta predes-
tinação”. Ela surge em duas variedades: boa sorte, quando alguma coisa aprazível acon-
tece inesperadamente, e má sorte, quando temos uma surpresa desagradável e alguma
coisa inesperada acontece. Dessa maneira, a sorte é como o risco – um evento futuro
incerto, que se acontecer, terá importância. Lembre-se de que o risco também tem
duas variedades: ameaças e oportunidades. Então desejar “Boa sorte” para alguém é o
mesmo que esperar que alguma oportunidade não planejada aconteça a ele.
Claro que a sorte acontece com todo mundo, incluindo ambas má sorte ou boa
sorte (da mesma forma que o risco afeta todos nós). O aspecto importante é o que
você faz com isso. Para evitarmos ser meras vítimas do que acontecerá conosco em
relação à sorte precisamos considerar dois aspectos.
Primeiro, devemos estar prontos para a sorte, tanto boa quanto má. Se você tives-
se uma surpresa desagradável no trabalho, o que faria? Você entraria em pânico, ou
ficaria paralisado sem fazer nada? Ou você responderia com um plano de contingên-
cia previamente preparado, talvez incluindo elementos de gestão de crises, recupe-
ração de desastres ou continuidade de negócio se necessário? E o que acontecerá se
você tiver boa sorte? Você ficará tão surpreso que não fará nada e desperdiçará a
oportunidade, ou terá um plano de contingência para aproveitar o benefício inespe-
rado? Como Louis Pasteur disse: “O acaso favorece somente a mente preparada.” Ou
de acordo com as palavras do filósofo romano Sêneca: “A sorte acontece quando a
preparação se encontra com a oportunidade.”
Segundo, não precisamos esperar a sorte se materializar. Podemos fomentar a
nossa sorte. O famoso jogador de golfe Gary Player observou: “Quanto mais eu pra-
tico, mais sorte tenho.” O Arcebispo William Temple teve uma experiência similar
e disse: “Quando eu oro, coincidências acontecem, e quando eu não oro, não aconte-
cem.” Se descobrirmos e atacarmos as causas da má sorte poderemos reduzir sua fre-
qüência e severidade. E da mesma maneira, se encontrarmos e influenciarmos as
causas da boa sorte poderemos ter mais surpresas agradáveis.
O importante não é o quão sortudo você é, mas sim o que você faz com a sorte que
tem. Então sim, eu desejarei “Boa sorte” para você – e a sabedoria de como lidar com
ela.
Cordialmente,
The Risk Doctor
Endereços Web para profissionais relacionados com gerenciamento de riscos:

UK Institute of Risk Management
www.theirm.org
UK Association of Insurance and Risk Managers

APÊNDICE E 471
www.airmic.com
Global Association of Risk Professionals
www.garp.com
Public Risk Management Association
www.primacentral.org
Risk Management Association
www.rmahq.org
Federation of European Risk Management Associations
www.ferma-asso.org
European Institute of Risk Management
www.eirm.com
Project Management Institute Risk Management Specific Interest Group
www.risksig.com
UKAPM Risk SIG
www.eurolog.co.uk/apmrisksig
International Association of Contrast and Commercial Managers (IACCM)
http://www.iaccm.com/
International Council on Systems Engineering (INCOSE) Risk Management
www.incose.org
Insurance Institute of America
www.aicpcu.org
Risk Management Institute of Australia
www.arima.com.au
Professional Risk Managers’ International Association (PRMIA)
www.prmia.org
CURRÍCULO DO DR. DAVID HILSON

“Dr David Hillson is an international risk management consultant and Director of
Risk Doctor & Partners (www.risk-doctor.com), offering specialist risk manage-
ment consultancy and training. He has wide personal experience in supporting
major UK and international projects across a range of industries. He also provides
specialist risk management training in the UK, Europe and US. His clients include
major organisations in construction, telecommunications, pharmaceutical, trans-
port, energy, IT, defence and government.
Over a period of nearly fifteen years consulting, David has become recognised in-
ternationally as a leading thinker and practitioner in risk management, and he is a po-
pular conference speaker and author on the subject, winning several awards for his
papers. His speciality is risk technology transfer, assisting organisations to develop
effective in-house risk processes. He has developed a number of innovative approa-
ches to identifying, assessing and managing risk, which have been widely adopted.
These include the Risk Breakdown Structure (RBS) to provide a framework for the

risk process, risk metalanguage to ensure accurate risk identification, the “mirror”
Probability-Impact Matrix for assessing both threats and opportunities, defined res-
ponse strategies for focusing action, maturity-model frameworks for benchmarking
risk management capability, and criteria for defining a professional approach to risk
management (the Risk Management Professionalism Manifesto). Most recently Da-
vid has been working on inclusion of proactive opportunity management in the risk
process, and this is the subject of his latest book.
Dr Hillson was elected a Fellow of the UK Association for Project Management
(APM) in recognition of his contribution to developing the discipline of risk manage-
ment. He is past Chairman of the APM Specific Interest Group (SIG) on Risk Mana-
gement, and is a core member of the team updating the Project Risk Analysis & Ma-
nagement (PRAM) Guide. He is also a Fellow of the UK Institute of Risk Manage-
ment (IRM), and is an active member of the International Council On Systems Engi-
neering (INCOSE) Risk Management Working Group.
David Hillson has been active for many years in the global Project Manage-
ment Institute (PMI®), particularly in the PMI Risk SIG of which he was a Foun-
der Member. In 2002 he was honoured with the PMI Distinguished Contribu-
tion Award for his sustained contribution to advancing the field of risk manage-
ment. David has been among the most popular presenters for PMI Seminars
World since 1999. He is part of the core team responsible for updating the risk
management chapter of the PMI Guide to the Project Management Body of
Knowledge (PMBoK®). He is a certified PMI Project Management Professional
(PMP®), and advises PMI HQ on education policy as part of the Education Mem-
bers Advisory Group.
Prior to developing a formal interest in risk management, David Hillson was a
project manager in a major UK engineering company, responsible for the successful
delivery of a number of large, multi-million pound, real-time software-intensive
projects. He has also been a member of the Chartered Management Institute for
many years, reflecting his broad interest in management topics beyond his own spe-
cialisms of project and risk management”.

Bibliografia
BARON, David. As leis de Moisés para a gerência: 50 lições de liderança do maior administrador de todos os
tempos. Rio de Janeiro: Record, 2002.
BERNHOEFT, Renato. Governança na empresa familiar: gestão, poder e sucesso. Rio de Janeiro: Cam-
pus/Elsevier, 2003.
BLOCK, Thomas R. The Project Office: A Key to Managing Project Effecively. Menlo Park, California:
Crisp Management Library, 1998.
CHARAM, Ram. Governança corporativa que produz resultados: como integrar conselhos de administração e
diretorias para gerar vantagem competitiva. Rio de Janeiro: Campus/Elsevier, 2005.
CHIAVENATO, Idalberto. Gestão de pessoas: o novo papel dos recursos humanos nas organizações. Rio de
Janeiro: Campus/Elsevier, 1999.
_____. Construção de talentos – coaching & mentoring. Rio de Janeiro: Campus/Elsevier, 2002.
_____. Planejamento estratégico: fundamentos e aplicações. Rio de Janeiro: Campus/Elsevier,
2004.
_____. Teoria geral da administração. 6a ed., vol. 1. Rio de Janeiro: Campus/Elsevier, 2001.
_____. Teoria geral da administração. 6a ed., vol. 2. Rio de Janeiro: Campus/Elsevier, 2001.
_____. Comportamento Organizacional. Rio de Janeiro: Campus/Elsevier, 2005.
CLELAND, David I. Field Guide To Project Management. Wiley, 2004.
_____ . Global Project Management Handbook. New Orleans, Louisiana: McGraw-Hill, 1994
_____. Project Manager’s Portable Handbook. New Orleans, Louisiana: McGraw-Hill, 2004.
_____. Systems Analysis and Project Management. New Orleans, Louisiana: McGraw-Hill, 1983.
_____. The Frontiers of Project Management Research. New Orleans, Louisiana: Project Management
Institute, 2002.
_____. The Strategic Management of Teams. Nova York: Wiley, 1996.
_____ e IRELAND, Lewis R. Gerência de Projetos. Rio de Janeiro: Reichmann & Affonso, 2002.

COHEN, Dennis J. Gestão de projetos/MBA Executivo: como transformar projetos em negócios de sucesso. Rio
de Janeiro: Campus/Elsevier, 2002.
CRAWFORD, Lynn. Project Categorization Systems: Aligning Capability with Strategy for Better Results.
Atlanta, GA: Project Management Institute, 2005.
DEMARCO, Tom. Waltzing with Bears: Managing Risk on Software Projects. Nova York: Dorset House,
2003.
_____. Peopleware: Productive Projects and Teams, 2nd ed. Nova York: Dorset House, 1999.
_____. The Deadline: A Novel About Project Management. Nova York: Dorset House, 1997.
DINSMORE, Paul Campbell. Como se tornar um profissional em gerenciamento de projetos. 2a ed. Rio de
Janeiro: Qualitymark, 2005.
_____. Transformando estratégias empresariais em resultados através da gerência por projetos. Rio de Janei-
ro: Qualitymark, 1999.
FAVARO, John. Managing Requirements for Business Value. Los Alamitos, CA: IEEE Software, 2002.
Harvard Business Review. Gestão e Implementação de Projetos. Rio de Janeiro: Campus/Elsevier, 2005.
HELDMAN, Kim. Gerência de projetos – Fundamentos: um guia prático para quem quer certificação em ge-
rência de projetos. Rio de Janeiro: Campus/Elsevier, 2005.
_____. Gerência de projetos: Guia para o exame oficial do PMI. 3a ed. Rio de Janeiro: Campus/Elsevier,
2006.
HILLSON, David. Effective Opportunity Management for Projects. Nova York: Taylor & Francis CRC
Press, 2003.
_____. Risky Rhymes - Uncertain Wit & Wisdom. Petersfield: Risk Doctor Publishing, 2005.
_____. The Risk Management Universe - A guided tour. Londres: BSi Business Information, 2006.
_____. Understanding and Managing Risk Attitude. Aldershot: Gower Publishing, 2005.
IT Manager’s Handbook: Getting Your New Job Done. Morgan Kaufmann Publishers.
KAPLAN, Norton. A estratégia em ação. 17a ed. Rio de Janeiro: Campus/Elsevier, 1997.
_____. Organização orientada para estratégia. 6a ed. Rio de Janeiro: Campus/Elsevier, 2000.
KERZNER, Harold. Advanced Project Management: Best Practices on Implementation. 2a ed. Nova York:
John Wiley e Sons, Inc, 2003.
_____. Gestão de projetos: as melhores práticas. 2a ed. Porto Alegre: Bookman, 2006.
_____. Project Management Best Practices: Achieving Global Excellence. Nova York: John Wiley & Sons,
Inc., 2006.
_____. Project Management Case Studies. 2a ed. Nova York: John Wiley & Sons, Inc., 2006.
_____. Project Management Workbook and PMP/CAPM Exam Study Guide. 9a ed. Nova York: John Wiley
& Sons, Inc., 2006.
_____. Project Management: A Systems Approach to Planning, Scheduling, and Controlling. 9a ed. Nova
York: John Wiley & Sons, Inc., 2005.
_____. Strategic Planning: A Practical Guide. Nova York: John Wiley & Sons, Inc., 1997.
_____. Using the Project Management Maturity Model: Strategic Planning for Project Management. 2a ed.
Nova York: John Wiley & Sons, Inc., 2005
KOTLER, Philip. Administração de marketing: A edição do novo milênio. 10a ed. São Paulo: Prentice Hall,
2000.
LAUDON, Ken. Management Information Systems: Managing the Digital Firm. 7a ed. Prentice Hall.
LODI, João Bosco. Governança corporativa. Rio de Janeiro: Campus/Elsevier, 2000.
MANZ, Charles C. Jesus, o maior executivo que já existiu: lições práticas de liderança para os dias de hoje. Rio
de Janeiro: Campus/Elsevier, 2006.
MAXIMIANO, Antônio Cesar Amaru. Administração de projetos: como transformar idéias em resultados.
2a ed. São Paulo: Atlas, 2002.

BIBLIOGRAFIA 475
McConnell, Steve. Professional Software Development: Shorter Schedules, Higher Quality Products, More
Successful Projects, Enhanced Careers. Boston: Addison-Wesley, 2004.
Mcmenamim, Steve. Essential Systems Analysis. Boston: Yourdon Press, 1984.
_____. Professional Software Development. Boston: Addison-Wesley, 2004.
MEREDITH, Jack R. e Mantel Jr. Samuel. Administração de projetos: uma abordagem gerencial. Rio de
Janeiro: LTC, 2000.
MURCH, Richard. Project Management: Best Practices for IT Professionals. New Jersey: Prentice
Hall.
PARDEE, William. To Satisfy and Delight your Customer. Nova York: Dorset House, 1996.
PFLEEGER, Shari. Software Engineering: Theory and Practice. New Jersey: Prentice Hall.
PMBOK 2000. Tradução livre do Capítulo PMI Minas Gerais.
PORCHÉ, Germanine e NIEDERER, Jed. Coaching: o apoio que faz as pessoas brilharem – orientação e
treinamento em qualquer situação. Rio de Janeiro: Campus/Elsevier, 2002.
PORTER, Michael et all. Planejamento Estratégico. Rio de Janeiro: Campus/Elsevier, 2002.
ROBERSON, Suzanne e James. Requirements-Led Project Management: Discovering David’s Slingshot.
Boston: Addison Wesley, 2005.
_____. Mastering the Requirements Process. 2a ed. Boston: Addison Wesley, 2006.
_____. Complete Systems Analysis: The Workbook, the Textbook, the Answers. Nova York: Dorset House,
1998.
SALIM, Simões. Construindo planos de negócio: todos os passos necessários para planejar e desenvolver negócios
de sucesso. 2a ed. Rio de Janeiro: Campus/Elsevier, 2003
SATZINGER, John. Systems Analysis and Design in a Changing World. Belmont: Thomson Learning.
SLYWOTZKY, Adrian. A arte do lucro. Rio de Janeiro: Campus/Elsevier, 2002.
SOROS, George. Globalização. Rio de Janeiro: Campus/Elsevier, 2002.
STONNER, Rodolfo. Ferramentas de planejamento: utilizando o MS Project para gerenciar empreendimen-
tos. Rio de Janeiro: E-paper, 2001.
The Project Management Institute Professional Code of Conduct (PMI).
Thomsett, Robb. Radical Project Management. Nova York: Dorset House, 2002.
TIGRE, Paulo Bastos. Gestão da inovação: a economia da tecnologia no Brasil. Rio de Janeiro: Campus/
Elsevier, 2006.
TURBAN, Efraim. Administração de tecnologia da informação: teoria e prática. Rio de Janeiro: Campus/
Elsevier, 2005.
_____. Decision Support Systems and Intelligent Systems. 7a ed. New Jersey: Prentice Hall, 2004.
_____. Electronic Commerce: A Managerial Perspective 2006. 4a ed. New Jersey: Prentice Hall, 2005.
_____. Information Technology for Management: Transforming Organizations in the Digital Economy. Nova
York: John Wiley & Sons, 2005.
_____. Introduction to Information Technology. Nova York: Wiley, 2004.
_____. Tecnologia da informação para gestão: transformando os negócios na economia digital. 3a ed. Porto
Alegre: Bookman, 2004.
GUIA PMBOK. Um guia do conjunto de conhecimentos em gerenciamento de projetos, Terceira Edição. New
Orleans: Project Management Institute, 2004.
USEEM, Michael. Liderando para o alto: como conduzir seu chefe em benefício de ambos. Rio de Janeiro:
Campus/Elsevier, 2002.
VARGAS, Ricardo Viana. Gerenciamento de projetos: estabelecendo diferenciais competitivos. Rio de Janei-
ro: Brasport, 2000.
VERMA, Vijay K. Human Resource Skills for the Project Manager: The Human Aspects of Project Manage-
ment. Vol. 2. New Orleans: Project Management Institute, 1996.

_____. Managing the Project Team: The Human Aspects of Project Management. Vol. 3 New Orleans: Pro-
_____. Organizing Projects for Success: The Human Aspects of Project Management. Vol. 1 New Orleans:
VERZUH, Eric. MBA Compacto - Gestão de Projetos. Rio de Janeiro: Campus/Elsevier, 2000.
WEILL, Peter. Governança de TI, Tecnologia da Informação. São Paulo: M. Books, 2006.
WHITTEN, Jeffrey L., et al. Systems Analysis and Design Methods. 5a ed. Nova York: McGraw Hill.
WIDEMAN, Max. A Management Framework for Project, Program and Portfolio Integration. Victoria:
Trafford, 2004.
_____. Cost Control of Capital Projects: and the Project Cost Management System Requirements. Richmond:
BiTech, 1995.
_____. Project & Program Risk Management: A Guide to Managing Project Risks and Opportunities. New
Orleans: Project Management Institute, 1992.
XAVIER, Carlos Magno da Silva. Metodologia de gerenciamento de projetos – Methodware: Abordagem prá-
tica de como iniciar, planejar, executar, controlar e fechar projetos. Rio de Janeiro: Brasport, 2005.

Gerenciamento de Projetos de Tecnologia Da Informação (Marconi Vieira)

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Gerenciamento de Projetos de Tecnologia Da Informação (Marconi Vieira)

Enviado por

Direitos autorais:

Formatos disponíveis

GERENCIAMENTO DE PROJETOS

CAMPUS — GERENCIAMENTO DE PROJETOS DE TECNOLOGIA DA INFORMAÇÃO — 1202 — CAPÍTULO 21 — 2ª PROVA

Consulte também nosso catálogo

CAMPUS — GERENCIAMENTO DE PROJETOS DE TECNOLOGIA DA INFORMAÇÃO — 1202 — CAPÍTULO 21 — 2ª PROVA

CAMPUS — GERENCIAMENTO DE PROJETOS DE TECNOLOGIA DA INFORMAÇÃO — 1202 — CAPÍTULO 21 — 2ª PROVA

Todos os direitos reservados e protegidos pela Lei 9.610 de 19/02/1998.

Copidesque: Carolina Godoi da Costa

ISBN 13: 978-85-352-2273-9

V716g Vieira, Marconi Fábio

06-3470. CDD 658.404

CAMPUS — GERENCIAMENTO DE PROJETOS DE TECNOLOGIA DA INFORMAÇÃO — 1202 — CAPÍTULO 21 — 2ª PROVA

CAMPUS — GERENCIAMENTO DE PROJETOS DE TECNOLOGIA DA INFORMAÇÃO — 1202 — CAPÍTULO 21 — 2ª PROVA

CAMPUS — GERENCIAMENTO DE PROJETOS DE TECNOLOGIA DA INFORMAÇÃO — 1202 — CAPÍTULO 21 — 2ª PROVA

Um agradecimento especial ao mestre, amigo e escritor Danúbio Becker Borba

CAMPUS — GERENCIAMENTO DE PROJETOS DE TECNOLOGIA DA INFORMAÇÃO — 1202 — CAPÍTULO 21 — 2ª PROVA

 Francesco de Cicco, Sócio-fundador e Diretor-executivo do QSP (Centro de

Agradeço a Joann Skiba, Director, IP and Business Product Development, da

CAMPUS — GERENCIAMENTO DE PROJETOS DE TECNOLOGIA DA INFORMAÇÃO — 1202 — CAPÍTULO 21 — 2ª PROVA

CAMPUS — GERENCIAMENTO DE PROJETOS DE TECNOLOGIA DA INFORMAÇÃO — 1202 — CAPÍTULO 21 — 2ª PROVA

CAMPUS — GERENCIAMENTO DE PROJETOS DE TECNOLOGIA DA INFORMAÇÃO — 1202 — CAPÍTULO 21 — 2ª PROVA

Pode ser contatado em: marconi@infochoice.com.br e marconivieira@compu-

CAMPUS — GERENCIAMENTO DE PROJETOS DE TECNOLOGIA DA INFORMAÇÃO — 1202 — CAPÍTULO 21 — 2ª PROVA

Desde meados de 1990, o gerenciamento de projetos tem apresentado um cresci-

CAMPUS — GERENCIAMENTO DE PROJETOS DE TECNOLOGIA DA INFORMAÇÃO — 1202 — CAPÍTULO 21 — 2ª PROVA

porária ou de projetos, na qual todos os esforços são orientados para os objetivos,

CAMPUS — GERENCIAMENTO DE PROJETOS DE TECNOLOGIA DA INFORMAÇÃO — 1202 — CAPÍTULO 21 — 2ª PROVA

CAMPUS — GERENCIAMENTO DE PROJETOS DE TECNOLOGIA DA INFORMAÇÃO — 1202 — CAPÍTULO 21 — 2ª PROVA

era assunto de engenheiros e profissionais de Tecnologia da Informação está se disse-

Professor Danúbio Borba Beker Borba, PMP

CAMPUS — GERENCIAMENTO DE PROJETOS DE TECNOLOGIA DA INFORMAÇÃO — 1202 — CAPÍTULO 21 — 2ª PROVA

Quando se publica a segunda edição de um livro, em primeiro lugar, é necessário

CAMPUS — GERENCIAMENTO DE PROJETOS DE TECNOLOGIA DA INFORMAÇÃO — 1202 — CAPÍTULO 21 — 2ª PROVA

CAMPUS — GERENCIAMENTO DE PROJETOS DE TECNOLOGIA DA INFORMAÇÃO — 1202 — CAPÍTULO 21 — 2ª PROVA

Além disso, foram adicionados três Apêndices: “Seleção de 50 Conceitos de Ges-

Marconi Fábio Vieira, PMP

CAMPUS — GERENCIAMENTO DE PROJETOS DE TECNOLOGIA DA INFORMAÇÃO — 1202 — CAPÍTULO 21 — 2ª PROVA

CAMPUS — GERENCIAMENTO DE PROJETOS DE TECNOLOGIA DA INFORMAÇÃO — 1202 — CAPÍTULO 21 — 2ª PROVA

Otimização do processo de tomada de decisão em TI . . . . . . . . . . . . . . . 29

CAPÍTULO 2 O contexto e os processos do gerenciamento de projetos . . . . . . 73

CAPÍTULO 3 O gerente de projetos antenado . . . . . . . . . . . . . . . . . . . . . . . . . . 79

CAMPUS — GERENCIAMENTO DE PROJETOS DE TECNOLOGIA DA INFORMAÇÃO — 1202 — CAPÍTULO 21 — 2ª PROVA

CAPÍTULO 4 As peculiaridades dos projetos de tecnologia da informação

CAPÍTULO 6 Grupos de processos de planejamento . . . . . . . . . . . . . . . . . . . . 163

CAMPUS — GERENCIAMENTO DE PROJETOS DE TECNOLOGIA DA INFORMAÇÃO — 1202 — CAPÍTULO 21 — 2ª PROVA

Planejamento do gerenciamento de riscos (11.1) . . . . . . . . . . . . . . 171

CAPÍTULO 7 Processos de execução. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

CAPÍTULO 8 Processos de monitoramento e controle . . . . . . . . . . . . . . . . . . 181

CAMPUS — GERENCIAMENTO DE PROJETOS DE TECNOLOGIA DA INFORMAÇÃO — 1202 — CAPÍTULO 21 — 2ª PROVA

CAPÍTULO 9 Processos de encerramento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

CAMPUS — GERENCIAMENTO DE PROJETOS DE TECNOLOGIA DA INFORMAÇÃO — 1202 — CAPÍTULO 21 — 2ª PROVA

PRMIA – The Professional Risk Managers’ International Association . . . 221

CAPÍTULO 11 Exemplos de softwares de gerenciamento de projetos . . . . . . . 243

CAMPUS — GERENCIAMENTO DE PROJETOS DE TECNOLOGIA DA INFORMAÇÃO — 1202 — CAPÍTULO 21 — 2ª PROVA

Task Tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244

CAMPUS — GERENCIAMENTO DE PROJETOS DE TECNOLOGIA DA INFORMAÇÃO — 1202 — CAPÍTULO 21 — 2ª PROVA

Contatos GanttHead . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285

CAMPUS — GERENCIAMENTO DE PROJETOS DE TECNOLOGIA DA INFORMAÇÃO — 1202 — CAPÍTULO 21 — 2ª PROVA

CAPÍTULO 12 Fomentando projetos de tecnologia da informação na

Um toque especial do Autor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405

CAMPUS — GERENCIAMENTO DE PROJETOS DE TECNOLOGIA DA INFORMAÇÃO — 1202 — CAPÍTULO 21 — 2ª PROVA

CAMPUS — GERENCIAMENTO DE PROJETOS DE TECNOLOGIA DA INFORMAÇÃO — 1202 — CAPÍTULO 1 — 2ª PROVA

CAMPUS — GERENCIAMENTO DE PROJETOS DE TECNOLOGIA DA INFORMAÇÃO — 1202 — CAPÍTULO 1 — 2ª PROVA

 Realizar cálculos numéricos de alta velocidade e de grande volume.

Francesco de Cicco, Sócio-fundador e Diretor-executivo do QSP (Centro de

Realizar cálculos numéricos de alta velocidade e de grande volume.

Aumentar a eficácia e a eficiência das pessoas trabalhando em grupos em um só

Um grande conjunto de produtos digitalizáveis (produtos que podem ser con-

Planejamento estratégico de TI: estabelece a relação entre o plano geral da em-

A estratégia competitiva da organização precisa ser considerada e refletida na

Efetividade: informação precisa no prazo, forma e formato adequado.

Alinhamento e entrega de valor por parte da área de TI para o negócio.