s ProjetoWBS GESTÃO PM News · segundo semestre de 2005 e já em clima de fim de ... pós-graduado em Marketing pela ESPM e Certificado no ... estatísticos do relatório KPMG, divulgado

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


- “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.


Í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


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.


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.


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


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 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.


• 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


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 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.


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


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


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


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


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


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”.


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.


É 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-


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.


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


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.


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


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


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


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


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.


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.


Sobre o Autor

Renato Machado de Oliveira, MBA, PMP

[email protected]

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

Documents

s ProjetoWBS GESTÃO PM News · segundo semestre de 2005 e já em clima de fim de ... pós-graduado em Marketing pela ESPM e Certificado no ... estatísticos do relatório KPMG, divulgado