s ProjetoWBS GESTÃO PM News · segundo semestre de 2005 e já em clima de fim de ... pós-graduado...
-
Upload
hoangkhuong -
Category
Documents
-
view
213 -
download
0
Transcript of s ProjetoWBS GESTÃO PM News · segundo semestre de 2005 e já em clima de fim de ... pós-graduado...
Gestão PM News Ano 3 – No. 8 www.gestaopm.com.br 1/27
WBSProjetos
GESTÃO PM News Ano 3 – N° 8 – São Paulo
Agosto-Dezembro de 2005
Editorial
Prezados Colegas,
é com grande prazer que publicamos a 8.a edição da “Gestão PM News”, a edição do
segundo semestre de 2005 e já em clima de fim de ano, na qual contamos com os artigos:
- “Estruturas Organizacionais, Rede Informal e a Síndrome da Ovelha”, que aborda os
aspectos não técnicos do gerente de projetos, destacando a influência na
organização.
- ” Iniciando um Projeto - Análise de Requisitos para Sistemas de Informações , que
aborda o grande desafio da gestão de requisitos, fator chave na estruturação do
escopo em projetos de TI.
- “Por que eficiência em risco é um aspecto chave de melhores práticas de projetos”,
tratando da importância da gestão de riscos e da aplicação da dose certa de
formalismo (relativização) e da complexidade das técnicas de acordo com o porte,
complexidade e criticidade do projeto.
Gerenciamento
Gestão PM News Ano 3 – No. 8 www.gestaopm.com.br 2/27
- “Administrando seu Portfolio Individual de Projetos”, que sintetiza alguns conceitos
importantes sobre o tema (gerenciamento de portfolio e balanced scorecard) e propõe
sua adaptação para outros níveis hierárquicos da organização.
Saudações e um 2006 baseado no crescente profissionalismo do gerenciamento de
projetos, podendo agregar cada vez mais valor aos negócios, resultando na melhoria da
taxa de sucesso dos desafios corporativos!
Augusto Camargos, PMP.
Gestão PM News Ano 3 – No. 8 www.gestaopm.com.br 3/27
Índice Remissivo
EDITORIAL..................................................................................................................................................... 1
ESTRUTURAS ORGANIZACIONAIS, REDE INFORMAL E A “SÍNDROME DA OVELHA” .......... 4 INTRODUÇÃO................................................................................................................................................... 4 INFLUÊNCIA NA ORGANIZAÇÃO ...................................................................................................................... 4 ESTRUTURAS ORGANIZACIONAIS .................................................................................................................... 4 REDE INFORMAL ............................................................................................................................................. 5 A SÍNDROME DA OVELHA ............................................................................................................................... 6 CONCLUSÃO.................................................................................................................................................... 6
INICIANDO UM PROJETO - ANÁLISE DE REQUISITOS PARA SISTEMAS DE INFORMAÇÕES............................................................................................................................................................................ 7
INTRODUÇÃO................................................................................................................................................... 7 PROJETOS DE SOFTWARE – RESULTADOS........................................................................................................ 8 O QUE SERIA REQUISITOS DE SISTEMAS? ......................................................................................................... 9 ERROS NA FASE DE ANÁLISE DE REQUISITOS. ................................................................................................. 9 CONSEQÜÊNCIA DE ERROS NA FASE DE ANÁLISE DOS REQUISITOS DE SOFTWARE......................................... 10 MÉTODOS DE ANÁLISE DE REQUISITOS......................................................................................................... 11 ELABORAÇÃO DO PLANO DE AÇÃO INICIAL PARA O DESENVOLVIMENTO DA ANÁLISE DE REQUISITOS ........ 14 CONCLUSÃO.................................................................................................................................................. 14
POR QUE EFICIÊNCIA EM RISCO É UM ASPECTO CHAVE DE MELHORES PRÁTICAS DE PROJETOS..................................................................................................................................................... 16
APLICAÇÃO ................................................................................................................................................... 19 ADMINISTRANDO SEU PORTFOLIO INDIVIDUAL DE PROJETOS ............................................... 21
RESUMO ........................................................................................................................................................ 21 INTRODUÇÃO................................................................................................................................................. 21 CONCEITOS IMPORTANTES ............................................................................................................................ 21 ADAPTAÇÕES NECESSÁRIAS ......................................................................................................................... 24 CONSIDERAÇÕES FINAIS................................................................................................................................ 26
Gestão PM News Ano 3 – No. 8 www.gestaopm.com.br 4/27
Estruturas Organizacionais, Rede Informal e a “Síndrome da
Ovelha”
Augusto Camargos, PMP.
IInnttrroodduuççããoo
Ser técnico ou não ser técnico?
Esta questão aplicada ao gerente de projetos é digna de muitos debates e explanações a
fim de deixar claro o papel e a missão da função em questão.
O próprio PMI reconhece que o gerente de projetos precisa ter conhecimentos dos
regulamentos e normas da área de atuação (área de aplicação). Não devemos entretanto,
confundir esta consistência exigida com a execução de atividades designadas à equipe do
projeto.
IInnfflluuêênncciiaa nnaa OOrrggaanniizzaaççããoo
O maior desafio normalmente do gerente de projetos são as questões não-
técnicas, ou seja, desafios que vão além das questões relacionadas às atividades
específicas do projeto.
Um dos grandes desafios do gerente de projetos é fazer as coisas acontecerem e para
isso a Influência na Organização é uma habilidade que merece destaque e é o foco deste
artigo.
É esperado do gerente de projetos uma atuação holística que vai desde o
alinhamento com a liderança organizacional, a alta administração, a negociação contínua
com os principais “stakeholders”, a manutenção de uma comunicação eficiente e de
acordo com o combinado, a tomada de decisão no tempo correto, a liderança e motivação
da equipe, em suma fazer o projeto acontecer apesar de todos os imprevistos que
provavelmente surgirão. Este é o papel do gerente de projetos: o de grande viabilizador,
facilitador, negociador, comunicador, líder, seja na diretoria à qual está diretamente
subordinado, seja por toda a organização na qual o projeto se insere.
EEssttrruuttuurraass OOrrggaanniizzaacciioonnaaiiss
Para entendermos melhor os desafios organizacionais, podemos dividir a
organização nas suas estuturas formais e informais, o que consequentemente gera
poderes e influências formais e informais.
Gestão PM News Ano 3 – No. 8 www.gestaopm.com.br 5/27
Por estruturas formais deve-se compreender a estrutura organizacional da
empresa, que vai desde o modelo funcional/departamental, o modelo matricial, o modelo
projetizado e o modelo misto (mistura dos demais). É claro que a forma de fazer o projeto
acontecer terá suas diferenças e peculiaridades nas diferentes estruturas organizacionais.
Na estrutura funcional o a atuação do gerente de projetos (que muitas vezes não tem o
cargo formal) é calcada pelo direcionamento dos gerentes funcionais, enquanto na
estrutura projetizada ele têm amplos poderes para demandar e negociar. Na estrutura
matricial o gerente de projetos responde pelo projeto e às vezes ao chefe geral dos
gerentes de projeto, mas continua hierarquicamente ligado à um gerente funcional. É bom
ressaltar que não existe uma estrutura ideal ou melhor, na verdade o desafio é tirar o
melhor de cada estrutura em favor ao sucesso do projeto.
Por estruturas informais podemos destacar as várias influências além dos cargos
formais, que vão desde o conhecido poder das secretárias, colaboradores com
experiência em determinado segmento e de uma forma generalizada na empresa
destaca-se o poder e conseqüências geradas pela comunicação informal.
RReeddee IInnffoorrmmaall
A rede informal, “grapevine” ou “rádio peão” é uma realidade nas organizações e
apesar de despertar diferentes sentimentos nos gerentes e executivos não pode ser
simplesmente eliminada, portanto deve ser compreendida e analisada em cada empresa.
Usualmente a rede informal é rápida, atua paralelamente à comunicação formal, agindo
sobre esta e vice-versa. Ou seja, a “rádio peão” pode influenciar decisões da gerência
assim como as decisões comunicadas pela gerência certamente movimentarão a “rádio
peão”.
Existem correntes que acreditam que a rede informal circula qualquer informação,
mas segundo a pesquisa de Keith Davis se mostrou bem seletiva, circulando por onde
realmente poderia gerar impacto. Segundo ainda Keith Davis a rede informal ocorre
predominantemente dentro da empresa e não em encontros e relacionamentos fora do
trabalho, fato que potencializa a ação e influência gerencial sobre esta. A rede informal é
um fator que deve ser levado em conta pelo nível gerencial. Os gerentes por sua vez
devem analisá-la em sua organização e tentar influenciá-la, ou seja, revertê-la em forças
que agreguem aos desejos e estratégias formais da empresa.
Gestão PM News Ano 3 – No. 8 www.gestaopm.com.br 6/27
AA SSíínnddrroommee ddaa OOvveellhhaa
Com todos os fatores formais e informais que permeiam a empresa, além é claro
de fatores externos, o que não podemos como gerentes de projetos é cair na síndrome da
ovelha, a miopia da ingenuidade técnica. Uso esta figura de linguagem para deixar claro
que nem sempre a ovelha pastando nos campos ensolarados, tranqüila e segura pelo seu
pastor, está livre de surpresas variadas; como por exemplo lobos e outros animais
selvagens capazes de acabar com a suposta estabilidade do pobre ovelha, que apenas
pastava de acordo com o que era esperado dela.
CCoonncclluussããoo
Portanto para que o gerente de projetos alcance o óbvio esperado dele, que é o
sucesso do projeto, deve estar atento a todas influências formais, informais, internas e
externas, para que só restem apenas as surpresas realmente inevitáveis de qualquer
projeto um pouco mais complexo.
Sobre o autor Antonio Augusto Camargos é formado em Computação pela UFSCar, pós-graduado em Marketing pela ESPM e Certificado no PMI (Project Management Institute) como PMP. Atua como Gerente de Projetos em TI na área financeira, como Palestrante, Instrutor do Curso Preparatório de Certificação PMP da Dinsmore Associates e Professor do Curso de Pós-Graduação em Gerenciamento de Projetos da FIAP (Faculdade de Informática e Administração Paulista).
Referências Bibliográficas
Project Management Institute ; PMBOK® Guide Third Edition
Argyris, Chris; Comunicação Eficaz na Empresa – Como Melhorar o Fluxo de Informações para Tomar Decisões Corretas – Harvard Business Review Book/ by Chris Argyris, Fernando Bartolomé, Carl R. Rogers e outros
Gestão PM News Ano 3 – No. 8 www.gestaopm.com.br 7/27
Iniciando um Projeto - Análise de Requisitos para Sistemas de
Informações
Ruggero Ruggieri
Introdução
A Análise de Requisitos é a fase de levantamento do problema a ser resolvido.
Nesta fase podemos identificar os limites e as reais necessidades do cliente para o
sistema. Podemos nesta fase limitar a análise exclusivamente ao problema em estudo, e
evitar os processos que estarão fora do problema. Na figura 1.1 é representado um
exemplo do ciclo de vida para o desenvolvimento de um software. Neste ciclo podemos
verificar que o papel da análise de requisitos é responsável pela identificação de
tendências tecnológicas que se não forem identificados a tempo, podendo tornar a
instalação de software deficiente, em alguns casos o projeto poderá ser recomeçado.
Figura 1.1
Cliente
Projeto deSoftware
Projeto deSoftwareProdução de
Software
Produção deSoftware
Análise deRequisitos
Análise deRequisitos
• Análise de Requisitos – Identificação dos problemas dos clientes.
• Projeto de Software – A partir dos requisitos, este processo é responsável
pela idealização das soluções do projeto.
Gestão PM News Ano 3 – No. 8 www.gestaopm.com.br 8/27
• Produção de Software – Nesta fase identificamos os processos pela
implementação dos elementos (programas, manuais, implantação, treinamento,
etc.).
Projetos de Software – Resultados
Segundo Booch, 1986: “devemos chamar atenção sobre o fato de que o
desenvolvimento orientado para objetos é um método que atinge o ciclo de vida apenas
parcialmente. Ele está focado sobre os estágios de projeto e implementação, no
desenvolvimento de software ....é imprescindível o acoplamento de métodos apropriados
de requisitos e análise, ao desenvolvimento orientado para objetos”. Segundo dados
estatísticos do relatório KPMG, divulgado em 1997.
• (A) Desvios de Cronograma
• (B) Excederam o custo estimado
• (C) Inadequados às necessidades de Negócios
O gráfico da figura 2.1 constata-se que as ferramentas de desenvolvimento de
programas de software e técnicas de desenvolvimento software melhoraram muito nos
últimos anos. Melhoras no prazo de entrega, melhorias no desenvolvimento, mas se ao
longo do ciclo de desenvolvimento os requisitos estiverem distorcidos ou não forem
adequadamente coletados, as distorções continuarão a acontecer.
Figura 2.1
87 %(A)
56 %(B)
45 %(C)
Ciclo de Vida de Projetos
Custos
Gestão PM News Ano 3 – No. 8 www.gestaopm.com.br 9/27
O que seria requisitos de sistemas?
Pela definição de Dean, 1994: “é qualquer coisa que restringe o sistema”. Segundo
SPCI (Software Productivity Consortium Incl): “os requisitos definem o problema. Eles lhe
dizem o que o software deverá fazer. Os demais passos do processo tradicional de
desenvolvimento de software criam solução”. Segundo Breitman, 1998: “A análise de
requisitos de software é a disciplina usada para capturar correta e complementando os
requisitos de software e expectativas dos usuários de software e as técnicas e disciplinas
da análise de requisitos de software tem como objetivo a elicitação de requisitos do
macrosistemas.” É a identificação das necessidades dos usuários de informações e
comunicação dessas necessidades aos processos de construção de software.
Figura 3.1
Algo que se deseja ouprecisa
caracterizar umcontrato padrão com
usuário
resolver um problemaou atingir um objetivo
do usuário
Análise deRequisitos
Análise deRequisitos
Análise do negócio
descrição completa "oque" e "como" deverá
ser feito
Segundo Pressman, 2000, define qualidade de software como: “conformidade a
requisitos funcionais e de desempenho explicitamente declarados a padrões de
desenvolvimento claramente documentados e a características implícitas que são
esperados de todo software profissionalmente desenvolvidos”.
Erros na fase de Análise de Requisitos.
A Análise de Requisitos é responsável pela identificação dos objetivos a serem
atingidos pelo software. Os erros cometidos durante a fase de análise, levarão a produção
do software inconsistente e o comprometimento do projeto.
Gestão PM News Ano 3 – No. 8 www.gestaopm.com.br 10/27
Conseqüência de erros na fase de Análise dos Requisitos de software.
A Análise dos Requisitos é responsável pela identificação dos objetivos do cliente.
Os levantamentos dos requisitos mal formulados, mal definidos ou incompletos, levarão
para a fase do projeto e no desenvolvimento do software. Conseqüentemente o projeto
ficará comprometido na medida em que os requisitos não forem consistentes e seguros.
Segundo a SPCI, os custos relativos para a eliminação dos mesmos problemas
nas etapas do desenvolvimento do projeto de software elevarão os custos 4X maior para
eliminação do erro na fase de testes e na fase de manutenção do software será 100X
maior.
Figura 5.1
Requisitos
Testes
Manutenção
Fases
Custos$
Segundo dados, Alan Daves, 1998: “56% de todos os erros encontrados nos
software, são originados na fase de análise de requisitos e 75% desses erros são
detectados somente depois das etapas de implementação e testes. As pesquisas da
KPMG, os erros de requisitos são distribuídos da seguinte forma conforme figura 5.2”.
Figura 5.2
Gestão PM News Ano 3 – No. 8 www.gestaopm.com.br 11/27
13%
31%
49%
2%
5%
devido a fatos incorretos
omissões
inconsistências
ambiguidades
Localização errada do requisitos
O Ministério da Ciência e Tecnologia (MCT), publicou em 1995 uma pesquisa
informando que 47,4% das empresas desenvolvedoras de software no Brasil utilizavam as
técnicas de Análise de Requisitos.
Figura 5.3
52,6%
47,4% Utilizam Análise de Requisitos Não Utilizam Análise de Requisitos
Conclusão: Muitos erros de projetos são cometidos e não são detectado no início
do projeto pela não utilização da técnica de Análise de Requisitos. Conseqüentemente, o
custo do projeto poderá crescer exponencialmente com o tempo.
Métodos de Análise de Requisitos
Reunião inicial com o Cliente – Nesta etapa inicial com o cliente, todos os participantes
interessados ou envolvidos no projeto deverão esta presentes. Elaborar um documento
visão sobre os assuntos que deverão ser abordados. Nesta fase, os usuários têm a
Gestão PM News Ano 3 – No. 8 www.gestaopm.com.br 12/27
liberdade de apresentarem toda a sua causa, todos os seus problemas, toda as sua
necessidades, enfim, têm a liberdade de falarem o que bem entenderem, sobre a questão
relativa a seu trabalho e sobre como acreditam que um sistema de informação proposto
possa, eventualmente, auxilia-los. Nesta fase, o entrevistador deverá ficar atento para as
expressões que:
• o usuário utiliza e que possam transparecer que ele sente necessidade de
informações;
• caracterizem problemas que ele vem sentindo;
• caracterizem objetivos de evolução da sua organização.
Esses aspectos precisam ser anotados. O que caracteriza a possibilidade de um sistema
de informações vir a ser útil é a presença de certas palavras, mas sentenças formuladas
pelo usuário tais como:
• Verbo “saber”, uma expressão do tipo “eu nunca sei...” ou “ eu gostaria de
saber...”. Outra característica é a presença de sentenças como: “eles me
perguntaram...” ou “o chefe questiona sobre...”. Essas sentenças são pistas de que
alguma informação é necessária.
• Os verbos “planejar” e “controlar” em todas as suas variações possíveis
(por exemplo “nossa meta é...”, “os estoques estão fora de controle...”); o controle,
como visto anteriormente, dá-se a partir da comparação dos dados resultantes do
planejamento versus os que são coletados na execução dos processos,
caracterizando, portanto, a necessidade de informações;
• Calcular, montar relatório, montar gráfico, registrar, consultar.
Um aspecto importante é que o entrevistador não deve solicitar detalhes sobre
qualquer informação que estiver sendo transmitida nessa fase do levantamento dos
dados. Não se sabe ao certo os efeitos da interferência do analista nesta fase, mas
nos casos em que isso ocorreu o cliente entrou em detalhes que em nada alteraram o
resultado final da análise, a não ser o fato de que o processo de levantamento de
dados tornou-se mais demorado. Além disso, desconfia-se que o desvio da atenção
do cliente sobre detalhes fazem com que o analista perca a noção da sua linha central
de pensamento, deixando de exprimir a completeza da natureza do problema como
seria direcionado pelo profissional. O principal aspecto que gerou essa desconfiança
foi o fato de surgirem elementos totalmente estranhos à questão que estava sendo
Gestão PM News Ano 3 – No. 8 www.gestaopm.com.br 13/27
apresentada, caracterizando a falta de coesão em determinados momentos do
raciocínio. Em hipótese nenhuma o entrevistador deverá ser estimulado, nessa fase,
com recomendações de possíveis relatórios ou consultas que o analista presume que
sejam importantes. A experiência indicou que o raciocínio dos clientes, sobre a
possibilidade de alguma funcionalidade ser disponibilizada por recomendação do
analista é de que se a funcionalidade não vier a ajudar provavelmente também não vai
atrapalhar, portanto, o analista provavelmente vai aceitar a sugestão,
independentemente da sua real necessidade em relação à sugestão dada. A
experiência indicou, também, que essas recomendações podem não ser úteis, mas
provavelmente tornará o projeto mais oneroso, mais lento ou demorado, quebra do
cronograma do projeto. Para ser implementados e podem dificultar a operação do
sistema, obrigando os usuários à alimentação de determinados conjuntos de dados
que não serviam ao propósito inicial do cliente.
Conclusão:
• Método pelo qual se chega a descoberta dos requisitos
• Causas de algumas reuniões ou requisitos não serem identificadas:
o Excessos de reuniões;
o Reuniões que consomem muito tempo – sem tempo pré-
determinados – sem coordenação;
o Reuniões ineficientes e improdutivas – falta de preparação.
Essencial para o sucesso de uma reunião – Antes da reunião, o Gerente de Requisitos
ou de Projetos, deverá enviar para os participantes, uma agenda informando o assunto,
participantes, tempo de início e final, papéis (definir o coordenador), problemas e
resultados esperados pelo assunto abordado e objetivo de cada participante. Enviar para
os participantes o material ou pauta da reunião.
Identificação de Sub-Sistemas (Particionamento) – O Gerente de Projetos ou Gerente
de Requisitos, deverá identificar nesta primeira fase das entrevistas os possíveis
desmembramentos do projeto de software. Os problemas freqüentemente são grandes
demais e muito complexos para serem compreendidos como um todo. O particionamento
divide o problema em partes mais facilmente entendidas. Através das interfaces
Gestão PM News Ano 3 – No. 8 www.gestaopm.com.br 14/27
estabelecidas entre as partes, a função global do software pode ser executada.
Particionamento Horizontal: decomposição funcional do problema. Particionamento
Vertical: expõem detalhes crescentes.
Elaboração do Plano de Ação Inicial para o desenvolvimento da Análise de Requisitos
Após a 1ª reunião com o usuário, identificados os objetivos dos sistemas, a
complexidade do desenvolvimento e a necessidade da criação de subgrupos para os
levantamentos do sistema. O Gerente de Projetos ou Gerente de Requisitos deverá
elaborar as técnicas de entrevistas e a metodologia de Requisitos para a elaboração do
desenvolvimento do software.
CCoonncclluussããoo
Com a necessidade da complexa indústria de software, os projetos corporativos
onde os serviços de adaptação do software às necessidades específicas de cada cliente,
causando interferência no processo de análise. Segundo Kaneko, 1994 – a indústria de
serviços a variedades de requisitos dos diversos consumidores complica a padronização
de cada tipo de serviço, que se deve proporcionar uma vez que os resultados desses
serviços raras vezes agradam a todos e, que quando agradam a maioria, normalmente
não proporcionam uma satisfação total. Segundo Gause, 1991, as pessoas assimilam
particularmente o que lhes parece conhecido ou lhes interessa. A não utilização da
Análise de requisitos, o desenvolvedor de software é levado a promover arranjos capazes
de comprometer seriamente o desenvolvimento. Com uma política este planejamento de
Particionamento horizontal
REQUISITOS
Particionamento Vertical
Gestão PM News Ano 3 – No. 8 www.gestaopm.com.br 15/27
qualidade de software e de requisitos os acordos entre as partes passam a ser mais
claros.
Sobre o Autor
Ruggero Ruggieri é Gerente de Projetos da Unidade PRODESP da Secretaria de Estado dos Negócios da Fazenda. [email protected] Referências Bibliográficas Dissertação sobre Análise de Requisitos para Sistemas de Informações, utilizando as
ferramentas da Qualidade de Processos de Software – Claudiomir Selner, 1999;
Artigo publicado na Revista BQ-Qualidade “As armas na defesa do meio Ambiente” – Luiz
Carlos de Martini Jr., 1999;
Trabalho de Apresentação sobre “Análise de Requisitos de Software e de Sistema” –
Professora Luciana Romani;
Ishikawa, 1993 – “Controle de Qualidade Total à maneira Japonesa”, Rio de Janeiro,
Editora Campos;
Booch, 1997 – Grady, James Rumbaugh e Ivar Jacobson – “The Unified Modeling
Language For Object-Oriented Development, www.rational.com;
SEPCI – Some Data on Software Development, Software Productivity Consortium Service
Corporation, Herdnon, Virginia;
Gerenciamento de Projetos – “Estabelecendo Diferenciais Competitivos” – 5ª Edição –
Ricardo Vargas;
Juran, J.M. – “A Qualidade desde o Projeto”, São Paulo, Editora Pioneira, 1992;
Trabalho de dissertação, Ana Elizabete Souza de Carvalho, Helena Cristina Tavares,
Joelson Brelaz Castro – Centro de Informática da Universidade Federal de Pernambuco –
“Uma estratégia para Implantação de uma Gerência de Requisitos Visando a Melhoria de
Processos de Software”;
Trabalho de dissertação, Claudia Hazam, Julio César Sampaio do Prado Leite –
“Indicadores para a Gerência de Requisitos”.
Gestão PM News Ano 3 – No. 8 www.gestaopm.com.br 16/27
Por que eficiência em risco é um aspecto chave de melhores
práticas de projetos
Tércia Rocha
Este artigo explica o que “eficiência em risco” significa, porque é aspecto chave de
melhores praticas e por que não se deve distribuir riscos no uso das práticas comuns
como publicam alguns autores. Explica também, como a eficiência em risco pode utilizar-
se das distribuições de probabilidades acumuladas (curvas-S) comparadas e por que
proporciona uma base para análise e decisão dos negócios de uma companhia.
Inicialmente, concordamos com Chris Chapman no que diz respeito à utilização de
eficiência em risco como aspecto chave das melhores práticas em projetos.
Entendemos que medir riscos utilizando ferramentas adequadas é importante para uma
sólida base de argumentação para:
• processos formais de gerenciamento formal de projetos de risco construído
para as necessidades corporativas;
• abraçar o gerenciamento de oportunidades assim como o de riscos;
• medir perigos e oportunidades para auxiliar a tomada de decisões;
• desenvolver uma cultura de arriscar mais eficiente; e
• arriscar mais para uma maior recompensa.
Basicamente, as incertezas relevantes são importante para a gestão de risco e
gerenciamento da qualidade de todos os projetos. O que importa é saber que partes do
projeto serão consideradas e seu comportamento em relação às incertezas e aos
objetivos estratégicos da companhia, gerenciando o escopo e seus requisitos, decidindo
por processos apropriados, seus custos e retornos, medindo a performance e os riscos
associados.
“Todos os envolvidos em fazer tais escolhas necessitam entender as implicações”,
conforme explicita Chris Chapman.
Gestão PM News Ano 3 – No. 8 www.gestaopm.com.br 17/27
É importante observar a profundidade e alcance da frase acima, visto que sua
simplicidade carrega conceitos abrangentes e de alta relevância quando tratamos de
relativizar o formalismo necessário para atender às melhores práticas na gestão de risco
do projeto e seu grau de aderência aos objetivos estratégicos da companhia.
Para que a relativização do formalismo seja possível sem ferir os conceitos de
melhores práticas é necessário e fundamental que o grau de maturidade da cultura
corporativa para riscos seja adequada para a tomada de decisão eficaz e eficiente.
A teoria do portfolio de Marcowizt, que apresenta a relação entre risco e retorno na
composição de uma carteira de investimentos, é bastante elucidativa quando aplicada à
análise de risco da companhia baseada em sua carteira de projetos. Essa analogia facilita
a compreensão sobre a importância da análise de risco na composição da carteira de
projetos da companhia e da eficiência em sua gestão.
A teoria de tomada de decisão inclui escolhas de múltiplos estágios retratados por
árvores de decisões e dependência estatística. Na prática, ambas estruturas (cursas S e
teoria do portfolio) precisam ser integradas e conjugadas. Neste aspecto, é importante
ressaltar a equivalência entre a gestão de risco na composição de um portfolio e a gestão
de risco eficiente dos projetos da companhia e gerenciamento global.
Os casos exemplarmente citados no artigo “Why risk efficiency is a key aspect of
best practice projects” levam ao entendimento de que as escolhas de soluções de menor
custo para projetos que tenham a probabilidade deocorrência de eventos não desejáveis
(riscos negativos) não são, em sua maioria, as melhores opções. Soluções mais custosas
poderão mitigar riscos e seus custos poderão ser diluídos ao longo dos prazos dos
projetos.
Uma equipe treinada para mitigar riscos de projetos inicialmente pode ser
entendida como acréscimo de custos para os projetos e para a companhia, mas quando
seus medidores retratam a eficiente e a eficaz utilização dos instrumentos de mitigação de
riscos, os valores agregados aos projetos e conseqüentemente à companhia serão
compreendidos como resultado positivo obtido com as melhores práticas da gestão de
negócio e risco de projeto da companhia.
Todas as opções definidas por pontos na curva de eficiência de risco minimizam o
risco para um dado nível de custo esperado e/ou minimizam o custo esperado para um
dado nível de risco. Elas são “Pareto Ótimo”, conhecidas também como a regra dos 20-
Gestão PM News Ano 3 – No. 8 www.gestaopm.com.br 18/27
80: para cada 20% dos itens analisados tem-se 80% dos resultados, definindo uma
fronteira eficiente. Não podemos fazer melhor em uma dimensão sem fazer pior em outra.
A eficiência na gestão dos riscos e seus custos consistem na análise da
combinação entre menores custos e riscos associados considerados aceitáveis para a
companhia. Decidir baseado neste conceito, apoiado em ferramentas simples de análise
permite otimizar e simplificar o nível operacional.
Nem sempre a melhor ferramenta para auxilio na tomada de decisão é perfeita
para todos os portes de projetos. É importante observar que projetos complexos e de
grande impacto para os negócios da companhia devem ser analisados de forma criteriosa
e neste caso cabendo inclusive uma maior formalidade no gerenciamento dos riscos do
projeto e o impacto desses na gestão do risco global da companhia.
Neste caso, a utilização de ferramentas mais complexas, onde seja possível medir
a combinação de diversos fatores e relacioná-los para atingir o ponto ótimo entre custo e
risco aceitável deve contemplar uma gama de variáveis suficiente (fator cubo) para atingir
o melhor resultado, o que não é possível com as ferramentas citadas acima na medição
de risco eficiente para projetos de porte e complexidade inferiores.
Por outro lado, caso a companhia não tenha maturidade suficiente para conviver
com alternativas de maior ou menor formalidade, graduadas pelo nível de complexidade
dos projetos e seus impactos, os tomadores de decisão serão incapazes de discernir
entre boa sorte e bom gerenciamento e má sorte e mau gerenciamento o que acarreta
exposição de risco desnecessária e de conseqüências não previsíveis , ou arriscadas,
para a companhia.
O centro de tudo isso é o papel dos trade-offs entre atributos como custo, tempo e
qualidade – muitas vezes imprecisos, mas normalmente críticos. Se este entendimento é
alcançado, o uso informal do conceito das melhores práticas de gerenciamento de risco
de projeto pode ser adotado de uma maneira efetiva para projetos muito simples, numa
escala mais ampla do que é adotado correntemente e entendido em termos de alcance
mais amplo do que algumas linhas mestras sugerem.
Gestão PM News Ano 3 – No. 8 www.gestaopm.com.br 19/27
AApplliiccaaççããoo
A maioria das empresas é bastante dependente de tecnologia, logo os exemplos
mais comuns estão focados na área de Tecnologia da Informação (TI).
Por ser crítica na gestão de projetos, a área de tecnologia das companhias utiliza
metodologia de desenvolvimento de sistemas que adota o gerenciamento de riscos com
base nos requisitos que atendem os objetivos estratégicos da companhia.
Dentro desse processo, o maior grau de formalidade é usado nos projetos de
manutenção da base tecnológica e nos aplicativos onde a segurança da informação é
critica.
Adota-se um grau de formalidade intermediário para sistemas onde o nível crítico
não envolva segurança da informação ou acesso de usuários externos (clientes).
Existe ainda a “informalidade” na gestão de requisitos para sistemas administrativos
utilizados internamente pelo staff.
Generalizadamente, nos casos de manutenção evolutiva também é utilizado um grau alto
de formalismo e para os casos de emergência existem procedimentos formais para o
tratamento específico de cada incidente.
Existe também procedimento formal para tratamento de incidentes e sua mitigação ou
contingência que poderá propiciar um ciclo de manutenções evolutivas.
Conscientes do elevado grau de criticidade dos negócios da companhia e a
necessidade de mitigação de riscos sem incorrer no erro “excesso de cuidado”, que em
muitos casos traria baixa eficiência em atingir os objetivos estratégicos da companhia,
desenvolvem modelos de gestão de risco onde a combinação da utilização de diferentes
graus de formalidade atinge o ponto que podemos chamar de “Pareto ótimo”.
Não é possível citar exemplos específicos visto que um dos pontos críticos que
permeiam sistemas de informação são os critérios utilizados para a mitigação de riscos
corporativos que consistem no sigilo de informações onde um dos itens para sua
mitigação é a assinatura, pelo staff, de contrato de sigilo, que trata dos deveres,
responsabilidades e penalidades aplicáveis, chegando estas ao limite das ações penais
cabíveis.
De qualquer forma, existem critérios claros de melhores práticas de gerenciamento
de risco para projetos e para as companhias de acordo com as práticas usuais nas
Gestão PM News Ano 3 – No. 8 www.gestaopm.com.br 20/27
companhias dependentes de tecnologia, adaptadas à necessidade de eficiência exigida
pelo mercado que atuam.
Este artigo foi escrito com base no trabalho “ Why risk efficiency is a key aspect of best
practice projects” escrito por Chris Chapman e publicado no International Journal of
Project Management em 2004 e com participação de Sara Alves, engenheira.
Sobre a Autora
Tércia Rocha é economista, pós-graduada em Mercado de Capitais pela EPGE/FGV e em
Gestão de Projetos pela POLI/USP.
Referencias Bibliográficas:
CMM – Capability Maturity Model;
Modelos para Gestão de Projetos, João Alberto Arantes do Amaral e Ricardo Sbragio;
A Qualidade Desde o Projeto – Os Novos Passos para o Planejamento da Qualidade em
Produtos e Serviços, J. M. Juran – Pioneira;
Creating The Project Office – A Menager´s Guide to Leading Organizational Change,
Randall L.Englund, Robert J. Graham; Paul C. Dinsmore;
Transformando Estratégias Empresariais em Resultados através da Gerência por
Projetos, Qualitymark.
Gestão PM News Ano 3 – No. 8 www.gestaopm.com.br 21/27
Administrando seu Portfolio Individual de Projetos
Renato Machado de Oliveira, MBA, PMP
RReessuummoo
Project Portfolio Management e Balanced Scorecard podem parecer assuntos
exclusivamente dos executivos de uma organização. A revisão e adaptação de alguns
conceitos para outros níveis hierárquicos, podem representar um grande avanço em
gestão para sua área ou equipe. Este artigo sintetiza alguns conceitos importantes sobre
o tema e propõe sua adaptação para outros níveis hierárquicos.
IInnttrroodduuççããoo
Na edição nº. 7 da “Gestão PM News”, publiquei o artigo “Project Portfolio
Management e o Balanced Scorecard”, onde foram descritos diversos conceitos e
defendida a necessidade de alinhamento estratégico do portfolio de projetos com os
objetivos estratégicos da organização.
Porém, sempre que se ouve falar de gerenciamento de portfolio de projetos é
comum imaginar uma disciplina exclusivamente coorporativa. E quando o assunto é
gerenciamento estratégico ou Balanced Scorecard a situação continua a mesma. Trata-se
de uma percepção equivocada sobre assuntos tão importantes para o direcionamento
estratégico em diferentes níveis organizacionais.
Qualquer posição de liderança precisa ter um mínimo de dedicação aos assuntos
estratégicos da sua área, de maneira a se proporcionar um direcionamento único e
consistente para sua equipe. E para cobrir esta lacuna deixada pelo primeiro artigo sobre
o tema decidi complementá-lo com algumas considerações adicionais.
CCoonncceeiittooss IImmppoorrttaanntteess
É necessário resgatar alguns conceitos importantes relacionados ao tema. A
intenção não é esgotar os assuntos, mas estabelecer uma base conceitual, que nos
permita validar a proposição deste artigo.
Project Portfolio Management
Nunca é demais lembrar que Gerenciamento do Portfolio de Projetos é mais do
que uma carteira ou coleção de projetos. Tão importante quanto selecionar e priorizar os
projetos que farão parte desta coleção é mantê-la atualizada e alinhada à estratégia da
Gestão PM News Ano 3 – No. 8 www.gestaopm.com.br 22/27
organização. É preciso conhecer a estratégia da organização e seus principais objetivos
antes de se construir ou gerenciar um Portfolio de Projetos.
Não basta apenas garantir que os projetos sejam executados respeitando-se seu
escopo, prazo e custo. O responsável pelo Gerenciamento do Portfolio de Projetos
precisa garantir que os projetos corretos sejam executados.
O processo de seleção, priorização e balanceamento de projetos pode considerar
diferentes critérios, métodos ou modelos. Como, por exemplo, as 5 etapas de HILL (2004)
que se inicia com a validação da estratégia de negócios e se encerra somente com o
estabelecimento de um ambiente sustentador de projetos, conforme abaixo (Figura 1):
Figura 1 – As cinco etapas para estabelecimento de um Portfolio de Projetos.
Representação do modelo de Hill.
Outro exemplo de método para balanceamento dos projetos que farão parte do
portfolio de uma organização é a abordagem que Kendall e Rollins (2003) defendem,
onde se propõe considerar inicialmente a capacidade das áreas de suporte, entrega de
produtos e serviços (Supply Side) e das áreas de vendas e marketing (Market Side). As
capacidades das áreas internas da organização são consideradas restrições neste
modelo, conforme representado abaixo (Figura 2):
1. Validar estratégia de negócio
5. Estabelecer ambiente sustentador de projetos 2. Identificar critérios
para seleção de projetos
3. Determinar mecanismos de seleção de projetos
4. Identificar papéis no PPM
Gestão PM News Ano 3 – No. 8 www.gestaopm.com.br 23/27
Figura 2 – Market Side e Supply Side - Representação do modelo de Kendall e Rollins Balanced Scorecard
KAPLAN e NORTON (1996) definem o Balanced Scorecard (BSC) como um
sistema gerencial de comunicação, informação e aprendizado, capaz de traduzir a missão
e estratégia de uma empresa ou unidade de negócios, em medidas claras e objetivas que
facilitam sua execução e acompanhamento. O Balanced Scorecard foi publicado
comercialmente pela primeira vez em 1996.
Basicamente, este sistema gerencial trabalha com objetivos estratégicos para as
perspectivas: financeira, do cliente, dos processos internos e do aprendizado e
crescimento. O resultado financeiro é, em última análise, uma conseqüência de se atingir
os objetivos estratégicos das outras perspectivas, como numa relação de causa e efeito.
É através da capacitação e aprendizado que os processos internos serão otimizados,
garantindo uma melhor percepção e satisfação dos nossos clientes e consequentemente,
os resultados financeiros (Figura 3).
FINANCEIRA
CLIENTE
PROCESSOS DE NEGÓCIO
APRENDIZADO E CRESCIMENTO
Lealdade dos clientes
Pontualidade das entregas
Ciclos dos Processos
ROCE
Qualidade dos Processos
Capacidades do funcionário
SUPPLY SIDE TI Engenharia P&D Manufatura Finanças Administração Aquisições
MARKET SIDE Vendas Marketing
CLIENTES MERCADO NEGÓCIOS
Gestão PM News Ano 3 – No. 8 www.gestaopm.com.br 24/27
Fonte: Robert S. Kaplan e David P. Norton, “A Estratégia em Ação - Balanced Scorecard”, Harvard Business School Press – 14ª edição
Figura 3 – Exemplo de relações de causa e efeito
AAddaappttaaççõõeess NNeecceessssáárriiaass
Os conceitos apresentados até este momento referem-se às organizações ou
unidades de negócio. No entanto, com algumas adaptações é possível transportá-los para
uma área ou equipe da organização onde o gerente de projetos tem autonomia e poder
de decisão.
SEU Portfolio de Projetos
A seleção e priorização de projetos de acordo com métodos, critérios ou modelos
previamente estabelecidos, também podem ser aplicados a uma área ou equipe da
organização com algumas adaptações.
Começando pelo modelo proposto por HILL (2004), suas 5 etapas poderiam
receber pequenas adaptações, conforme segue:
1. Validar a estratégia de negócios
Considere a razão de existência da sua equipe para a definição da sua missão e visão
de futuro. É importante voltar a esta definição, pelo menos, uma vez por ano para se
ter certeza de que o tempo não o fez desviar do rumo inicialmente planejado. Esta
definição será a estratégia de negócios da sua equipe.
2. Identificar os critérios para seleção de projetos
Pouco se muda em relação à definição inicial. Os critérios de seleção de projetos
precisam existir independentemente se o portfolio está no nível organizacional ou de
uma equipe específica.
3. Determinar mecanismos de seleção de projetos
Os mecanismos devem ser otimizados, considerar a real capacidade da sua equipe e
ser aceitos por seu superior imediato. Neste caso, a utilização de mais de um
mecanismo para selecionar os projetos que farão parte do portfolio da sua equipe
pode ser visto como algo muito burocrático e desnecessário. Por isso, utilize apenas
um mecanismo como, por exemplo, o Balanced Scorecard.
4. Identificar papéis no Project Portfolio Management
Gestão PM News Ano 3 – No. 8 www.gestaopm.com.br 25/27
Quem estará exercendo a função de gerente do portfolio de projetos será você
mesmo, de modo que esta etapa fica dispensada. O importante é não esquecer de
exercer cada um dos diferentes papéis.
5. Estabelecer um ambiente sustentador de projetos
Assim como estabelecer um ambiente favorável para o gerenciamento de projetos
para toda a organização, é importante que o mesmo ocorra em relação a sua própria
equipe. Seja um defensor dos princípios básicos do gerenciamento de projetos na sua
equipe e obtenha os resultados positivos desta postura.
No caso do Market Side e do Suply Side de Kendall e Rollins (2003), também
devem ser consideradas algumas adaptações. Os clientes, o mercado e os negócios a
considerar no Market Side são os clientes da sua área ou equipe e não os da
organização. A mesma analogia deve ser feita ao considerar as restrições impostas pelo
Supply Side, onde os limites estão na capacidade da sua própria equipe.
Criando SEU próprio BSC
Já existem no mercado algumas variações do tradicional Balanced Scorecard,
como por exemplo, o IT BSC, BSC para Projetos, entre outros. Estes “outros” Balanced
Scorecard na verdade, são apenas adaptações do modelo original proposto por Kaplan e
Norton.
Da mesma forma, com pequenas adaptações também podemos criar uma versão
de BSC para ser utilizado internamente numa equipe, ou seja, o SEU próprio BSC.
As adaptações devem começar já na escolha das perspectivas que serão
utilizadas para a definição dos objetivos estratégicos. Nem sempre é possível trabalhar
com a perspectiva financeira no BSC da sua própria equipe. Neste caso, a adaptação
deve ser feita substituindo-se esta perspectiva por outra que, em última instância,
represente os objetivos da área a que sua equipe pertence. Por exemplo, crie no SEU
próprio BSC com o nome da diretoria a que sua equipe pertence na primeira perspectiva.
Um cuidado deve ser tomado. Substituir todas as perspectivas poderá eliminar a
principal característica de um BSC, que é o balanceamento dos objetivos em perspectivas
que formam uma relação de causa e efeito sustentadora. Por isso, o ideal para este tipo
de adaptação é a substituição de apenas uma das perspectivas.
Gestão PM News Ano 3 – No. 8 www.gestaopm.com.br 26/27
A escolha dos objetivos deve ser feita em relação à sua própria equipe. Na
perspectiva dos clientes, por exemplo, devem ser considerados os clientes diretos da sua
equipe, sejam internos ou externos à organização. Analogamente, o mesmo deve ser feito
para as demais perspectivas.
Depois de estabelecidos os objetivos estratégicos das diferentes perspectivas,
deve-se identificar as relações de causa e efeito entre os objetivos. Principalmente,
devem-se mapear as relações de causa e efeito não tão evidentes, como por exemplo,
aquelas que ocorrem entre objetivos de perspectivas não adjacentes, como as
perspectivas “do Cliente” e “do Aprendizado e Crescimento”.
CCoonnssiiddeerraaççõõeess FFiinnaaiiss
A utilização dos conceitos de gerenciamento de portfolio de projetos e de gestão
estratégica através do Balanced Scorecard não pode ser uma atribuição exclusiva do
grupo de executivos da organização. Todos os líderes, nos diferentes níveis da
organização, devem se preocupar em manter um conjunto adequado de projetos
alinhados aos objetivos estratégicos da sua área ou equipe.
Salvo por pequenas adaptações, os processos de criação de um portfolio de
projetos alinhado à estratégia da sua equipe e balanceado entre as diferentes
perspectivas do BSC, deveria ser um processo comum a todos os níveis organizacionais.
O ideal é que a organização tenha sua missão e visão de futuro definidas e seus
objetivos estratégicos também definidos e divulgados a todos os seus colaboradores para
que os objetivos da sua área sejam derivados destes. Mas se, por qualquer razão, estas
informações não estiverem ao seu alcance, crie uma missão e visão de futuro da sua
própria equipe como base para a definição dos seus objetivos estratégicos.
Por último, outra consideração importante é a necessidade de uma ferramenta ou
software para gerenciar um portfolio de projetos ou um Balanced Scorecard. Não há a
necessidade de softwares sofisticados e caros como algumas ferramentas de Balanced
Scorecard, mas pelo menos, uma planilha eletrônica com algumas funções programadas
ajudaria muito.
Gestão PM News Ano 3 – No. 8 www.gestaopm.com.br 27/27
Sobre o Autor
Renato Machado de Oliveira, MBA, PMP
Atuou como gerente de projetos no Lloyds TSB Bank Plc, onde gerenciou diversos projetos de TI e participou do grupo executivo de implantação do Balanced Scorecard. Atualmente é responsável pela área de Metodologia e Qualidade de sistemas na Bolsa de Valores de São Paulo. Graduado em Tecnologia em Processamento de Dados pela Universidade Mackenzie em 1992, com Especialização de Informática pela mesma universidade em 1993 e MBA pela Fundação Dom Cabral, filiada a PUC-MG, em 2003. Certificado pelo PMI - EUA como Project Management Professional – PMP® em 2004.
Referências Bibliográficas KAPLAN, Robert S. e NORTON, David P. - A Estratégia em Ação: Balanced Scorecard - Rio de Janeiro - Editora Campus – 1997. KAPLAN, Robert S. e NORTON, David P. - Using the Balanced Scorecard as a Strategic Management System - Harvard Business Review - Volume 74 número 1 - Pág. 75 / 85 – 1996 KENDALL, Gerald I. E ROLLINS, Steven C. – Advanced Project Portfolio Management and the PMO – Multiplying ROI at Warp Speed – J.ROSS Publishing & International Institute for Learning, Inc. – 2003 HILL, Gerard M. – The Complete Project Management Office Handbook - Auerbach Publications © – 2004