O DNA do PMO

Autor: Jack S. Duggal, MBA, PMP Escritórios de Gerenciamento de Projetos (PMOs) estão ao redor já por algum tempo e se tornaram um elemento comum em muitas organizações. Apesar disso, o propósito central e a função de um PMO continua a ser questionado e debatido. A situação fica ainda mais complicada nas organizações em que os PMOs se proliferam em múltiplos níveis com sobreposição de funções ou funções conflitantes. Por outro lado, às vezes, quando não há clareza de propósitos, tendo um enfoque estreito acaba limitando o valor do PMO. Assim como o DNA contém as instruções genéticas utilizadas no desenvolvimento e funcionamento de todos os organismos vivos conhecidos, será que há um código que contém todos os elementos para a construção de um PMO bem sucedido? A forma específica, função e estrutura de um PMO para a sua organização vai depender de uma série de fatores como: seus desafios atuais e necessidades; o tamanho e o tipo da sua organização, a natureza e o escopo dos projetos; maturidade da sua organização de gerenciamento de projetos. No entanto, muitos dos elementos centrais de um PMO podem ser identificados e mapeados. Durante uma sessão do SeminarsWorld® tentamos decodificar o DNA, ou identificar os elementos centrais de um PMO bem sucedido, que poderia ser escalável e aplicado a qualquer tipo de organização ou negócio. Os Seis Elementos do DNA do PMO Para construir uma visão holística do PMO, uma visão integrada do PMO é necessária. O DNA do PMO ajuda a organizar as funções de PMO em seis grandes categorias, conforme mostrado abaixo: 1. Execução e desempenho: Enfoque nos aspectos táticos da execução do projeto, fornecendo processos padronizados, metodologias, ferramentas, modelos, treinamento e suporte para melhorar as capacidades de execução e entrega. 2. Suporte estratégico a apoio à decisão: Facilita o gerenciamento de portfólio, fornecendo informações para a seleção e priorização de projetos, destacando informações importantes para avaliar o risco, capacidade de recursos e gerenciamento de demanda e de apoio à decisão favorável ao alinhamento dos negócios, os benefícios de realização e gerenciamento de valor. 3. Governança: Estabelece uma estrutura de tomada de decisões para ligar a estratégia com a tática, e facilita as decisões-chave do projeto/programa, incluindo a definição de políticas, procedimentos e mecanismos de governança, que estabelece estágios. 4. A gestão de desempenho e relatórios: Fornece informações consolidadas e transparência com os relatórios relevantes que ajudam no controle e gerenciamento de projetos, programas e gerenciamento de portfólio. 5. Comunicação e gestão de relacionamento: Identifica as ligações e dependências, detecta falhas de comunicação e problemas de desempenho. Ainda resolve problemas de comunicações e questões de interface através de silos organizacionais, desenvolve e gerencia as relações com as partes interessadas. 6. Gestão de mudança organizacional: Como o gerenciamento de projetos é a ferramenta pela qual as mudanças acontecem, o PMO pode ajudar a facilitar e preparar para as mudanças. Os elementos acima referidos podem ser encontrados em um PMO típico, individualmente ou em combinações de duas ou mais, mas raramente todas as seis áreas. Como você aplica a idéia do DNA para o seu PMO? Avalie o seu PMO através da perspectiva de cada uma dos seis elementos, medindo as forças e fraquezas. Faça parte da comunidade de prática de Escritório de Gerenciamento de Projetos do PMI. Autor: Jack S. Duggal, MBA, PMP Sr. Duggal é diretor do Projectize Group LLC, palestrante e membro do PMI SeminarsWorld®

Por que Agile e Lean funcionam? Ou como explicar para seus executivos e líderes a hiperprodutividade que esses tais de agilistas conseguem!

Por José Papo

email: jpapo@hotmail.com

Analisando as pesquisas sobre sucesso de projetos encontramos números interessantes. De acordo com o Chaos Report de 2009, em torno de 30% dos projetos de TI são bem sucedidos. Enquanto isso, surveys sobre Agilidade mostram que em torno de 80% dos projetos Ágeis terminam com sucesso. E mais que isso: empresas como a SalesForce.com obtiveram uma melhoria de quase 400% no valor gerado após a adoção da cultura Ágil, em torno de 70% de redução nos defeitos e 50% de redução no time to market para lançamento de novas versões de seus produtos.Será mágica? Será Bala de prata? Não. Então como explicar os números impressionantes acima?Vou tratar um pouco dos 'segredos' do Agile / Lean funcionar tão bem quando ocorre uma mudança de paradigma real dentro da organização.Os dois pilares do Lean (e que podem ser encontrados também embutidos no Manifesto Ágil) são:- Respeito pelas pessoas- Melhoria contínuaPodemos resumir esses dois pontos nessa frase: "A raiz do Lean/Agile é ser um eterno insatisfeito com o status quo. Você tem que se perguntar continuamente: 'Por que estamos fazendo isso?' ". Portanto é possível compreender que o princípio de Eliminar desperdícios do Lean está umbilicalmente relacionado com o pilar positivo da melhoria contínua e da eterna insatisfação com a mesmice.Mas vocês devem estar se perguntando: Como isso explica a hiperprodutividade Agile? Vamos explicar agora, mas lembre-se de não tirar de sua cabeça os pilares: Respeito pelas pessoas e melhoria contínua com eliminação de desperdícios.Quando ocorre uma mudança de paradigma para o Lean, as pessoas da organização voltarão seus esforços para eliminar tudo aquilo que não agrega valor na cadeia produtiva. O livro dos Poppendieck levanta uma série de elementos para identificar os geradores de desperdícios na área de desenvolvimento de software. Mas eu vou focar nos dois mais importantes e que geram o maior impacto inicial na produtividade da empresa:- Projetos desnecessários- Requisitos desnecessáriosA adoção estratégica de Lean deve iniciar pelo esforço de Gestão Ágil de Portfólio de Projetos. Pela elaboração de business cases enxutos e continuamente avaliados para cada projeto da empresa. Conforme descrito por Donald Reinertsen em seu livro Desenvolvendo Produtos na Metade do Tempo: eliminar projetos com baixo retorno vai gerar mais velocidade no time to market dos projetos restantes. Apesar de contra-intuitivo, quando você corta projetos você entrega mais projetos num time to market menor! Esse nível mais estratégico do portfólio de projetos é pouco tratado em processos ágeis como Scrum, XP, OpenUP, etc. Porém é fundamental para a busca da hiperprodutividade.O próximo nível é o de requisitos desnecessários. É aí em que os processos ágeis possuem práticas e mecanismos orientados para que o desperdício de criar requisitos de pouco valor não ocorra. Aí também entra a necessidade de boas pessoas e bom time. Um bom product owner (desgraçado ganancioso, como meu amigo Yoshima gosta de resumir) é fundamental para que o desperdício (quase uma hemorragia, já que segundo o Chaos Report quase metade dos requisitos não agregam valor maior que o custo para produzí-los) estanque.Além disso, a filosofia e práticas da Agilidade/Lean focam na auto-organização do time, na responsabilidade conjunta pelos objetivos de negócio do projeto e na produtividade com qualidade e com ritmo sustentável. Todas elas são práticas de administração consagradas e evidenciadas por Peter Drucker para liderar trabalhadores do conhecimento. Nas palavras do próprio Peter Drucker: "Knowledge workers must take responsibility for managing themselves".No tocante à gestão de projetos também temos efeitos benéficos. O PMBOK já fala sobre o clássico ou quadrante mágico de variáveis do projeto. Ele é composto por escopo, custo, prazo e qualidade. Há também uma lei em relação a esse quadrante: das quatro variáveis, você só pode fixar três... uma irá variar.Num projeto tradicional cascata e com preço fixo (ainda no Brasil esse é o modelo mais usado, portanto o chamo de tradicional por causa disso) é fixado o custo, o prazo e o escopo. Acho que é fácil entender agora porque a maioria dos projetos de TI falha do ponto de vista dos stakeholders: o que varia é a qualidade... e ela varia lá pro fundo do buraco!Uma empresa Ági/Lean, entendendo que defeitos são o terceiro grande gerador de desperdícios, muda isso. Ela fixa o prazo, o custo e a qualidade(a qualidade é fixada quando usamos as práticas de engenharia Ágil. Sem elas você não será hiperprodutivo) e deixa variar o escopo. Essa mudança fundamental também ajuda a resolver o segundo desperdício: requisitos desnecessários. Quando o prazo e o custo são fixos, o product owner e os stakeholders terão que se esforçar ao máximo para atingir os objetivos de negócio almejados pelo projeto realizando apenas os requisitos importantes e de maior valor agregado, despriorizando ou eliminado requisitos de baixo valor. Veja como é exatamente isso que o cara que paga (sponsor) e outros stakeholders querem: um resultado (produto) de alta qualidade contendo o mínimo necessário de funcionalidades que resolvam seus problemas e necessidades de negócio, e ainda com a facilidade de mudar de idéia no decorrer do projeto.Algumas pessoas orientadas ainda pelo paradigma preço fixo costumam imediatamente perguntar o seguinte: isso significa que um projeto Ágil entrega menos escopo que um cascata? E respondo: Muito pelo contrário, ele entrega um escopo de maior qualidade e valor agregado para o negócio. E é isso que o faz ser visto como bem sucedido pela organização.Em resumo: Por que Agile / Lean funciona? Porque o respeito pelas pessoas e a busca da melhoria contínua levam à hiperprodutividade. Mas como essa hiperprodutividade ocorre quando ocorre a mudança de paradigma? Ela ocorre porque eliminam-se desperdícios das mais variadas formas e devido ao foco no resultado com ritmo sustentável. Os principais itens que geram isso no início são:- Eliminação ou redução de projetos de baixo valor agregado.- Eliminação ou redução de requisitos de baixo valor agregado.- Em relação ao quadrante de variáveis do projeto: fixar custo, prazo e qualidade e deixar variar o escopo.Não é fácil resumir o segredo do sucesso de algo, mas precisamos tentar. Esses segredos é que explicam a executivos e stakeholders porque adotar a filosofia Ágil os levará a outro patamar e também esclarecerá que só o 'processo' Ágil e suas práticas não resolverão o cerne do problema. A organização precisa de um choque cultural para que a hiperprodutividade se torne uma realidade, assim como ocorreu na Salesforce e em outras empresas que precisam do desenvolvimento de software e sistemas para manter seus negócios.Um breve pensamento para fechar: "O Modelo tradicional cascata é errado e perigoso. Nós temos que superá-lo." - Frederick Brooks, autor do livro 'The Mythical Man-Month', em seu novo livro 'The Design of design'

IN4/TCU: Entendendo o fenômeno que está acontecendo nas pautas de TI no Governo Federal

Por Wanderson Alves de Lima

Em vigor desde 02 de Janeiro de 2009, a IN4 (Instrução Normativa Nº 4) da SLTI (Secretaria de Logística e Tecnologia da Informação) disciplina as contratações de serviços de Tecnologia da Informação pelos órgãos e entidades integrantes do SISP (Sistema de Administração dos Recursos de Informação e Informática), segundo os princípios de:
1) alinhamento entre planejamento de contrações e estratégia organizacional;
2) modelo do processo de contratação estruturado, baseado em fases, papéis, responsabilidades e documentos de apoio;
3) contratação e remuneração baseada em resultados; e
4) gestão dos processos de TI e da segurança da informação privativa da Administração pública.

Esses princípios visam melhorar o quadro levantado no Acórdão 1603/2008, da Governança de Tecnologia da Informação na Administração Pública Federal, onde foram identificados os seguintes problemas principais:
• Ausência de planejamento estratégico institucional e de TI;
• Deficiência na estrutura de pessoal;
• Tratamento inadequado à confidencialidade, integridade e disponibilidade das informações.

Um dos objetivos da governança de TI é assegurar que as ações de TI estejam alinhadas com os objetivos da instituição, contribuindo para alcançá-los. O desempenho da área de TI deve ser medido, os recursos propriamente alocados e os riscos inerentes, mitigados. Assim, é possível gerenciar e controlar as iniciativas de TI nas instituições para garantir o retorno de investimentos e a adoção de melhorias contínuas nos processos organizacionais. Garantir a correta aplicação dos recursos empregados em tecnologia da informação torna-se cada vez mais importante, tendo em vista que, somente na Administração Federal, o gasto em TI ultrapassa R$ 6 bilhões por ano, segundo dados do SIAFI (Sistema
Integrado de Administração Financeira) e do DEST (Departamento de Coordenação e Governança das
Empresas Estatais).
Para garantir que os investimentos promovam valor às organizações, é necessário que eles sejam realizados à luz de um planejamento baseado em objetivos e estratégias de como alcançá-los. Apenas elencando as iniciativas e programas a partir da distância entre a situação desejada e a situação atual, a TI conseguirá fornecer o melhor apoio à organização e, conseqüentemente, o retorno de investimento.
Assim, faz-se altamente necessária a definição da visão (aonde quer chegar) e os objetivos (como irá chegar à visão) da instituição para que a área de TI possa engenhar os processos de trabalho e derivar destes as demandas de automação para suportar os objetivos almejados. Desta forma, serão identificadas demandas de alto valor.
A partir daí, podemos avançar para o desafio seguinte: como priorizar essas demandas e desenvolvê-las de forma a alcançar soluções de alta qualidade, de menor custo, de alta adaptabilidade às mudanças e que reutilize os recursos/soluções já adquiridas pelo Governo Federal?
Assim, a IN4 regulamenta também o uso de pregão eletrônico na contratação de serviços, na aquisição e
produtos e no desenvolvimento de projetos de TI por terceiros no âmbito da administração pública federal.
Nas metas do governo destacam-se: a realização de contratações individuais em detrimento de contratos
guarda-chuva; a redução da dependência de terceiros assumindo para si os papéis de gestão e coordenação de TI; e alcançar soluções de melhor qualidade e de menor custo.
Hoje, a aquisição de produtos e commodities pelo Governo Federal já está bastante estruturada conforme o modelo do pregão eletrônico. As solicitações são realizadas com um alto nível de detalhes sobre os produtos, garantias e dinâmica de aceitação. No entanto, para a aquisição de serviços, dado sua natureza mais intangível, o uso de pregão eletrônico exige um cuidado maior na sua especificação, detalhamento e
forma de medição – para oferecer uma interface clara entre o tomador e o executor dos serviços. Para serviços de TI, essa complexidade é elevada ao topo. O que pode ser feito a esse respeito?
Nas palavras do titular da SLTI, Rogério Santanna: “O pregão leva em conta o menor preço ofertado, e o que garante a qualidade é a boa especificação dos bens e serviços adquiridos”. Assim, o caminho para o sucesso na contratação de serviços de TI está em praticar processos maduros de gestão de demandas, que abordem todo o ciclo de vida das aplicações, desde o entendimento da necessidade pelas áreas fins e de TI, a especificação dos requisitos de automação, as definições de interface e padrões com o fornecedor, até a implantação das mudanças com eficiência e segurança.
Logo, cadenciando os processos envolvidos na gestão de demandas como a figura abaixo, tem-se os insumos necessários para utilização de pregão eletrônico.

Por fim, o processo de compra deve evoluir para oferecer uma comunicação cada vez mais efetiva entre comprador e fornecedor, estabelecendo padrões de especificação de necessidades, procedimentos para a gestão de mudanças, perfilando os fornecedores segundo seus conhecimentos e habilidades e valiando-os segundo seus resultados e trabalhos realizados. Interessante comentar que, como conseqüência da IN4, temos um movimento natural de elevação da profissionalização da indústria de TI. Tendo o TCU como indutor do processo de aperfeiçoamento da governança de TI, os órgãos e entidades do governo federal serão motivados a desenvolver seus planejamentos estratégico institucional e de TI, direcionando assim os investimentos em iniciativas de maior valor para a nação.
Com um local centralizado para conduzir o processo de terceirização, obtém-se uma democratização da
informação de fornecedores, clientes e os resultados dos relacionamentos entre eles. Apoiados por processos de gestão de demandas, métricas, base histórica e dinamismo no processo de terceirização, os clientes podem tomar melhores decisões na escolha dos seus fornecedores. Com isso, ao mesmo tempo em que é reforçada a competência e a responsabilidade dos fornecedores vitoriosos, é gerado um movimento de aprendizagem e de melhoria nos demais fornecedores para superar seus fatores negativos. Assim, a relação de terceirização de serviços de TI se tornada cada vez mais madura e o mercado cada vez mais profissional.
Diante dos benefícios levantados, conclui-se que a iniciativa do governo federal em implantar uma normativa que incentive a orientação estratégica de TI e regulamente o uso de pregões eletrônicos promoverá um salto de clareza e eficiência nos processos de terceirização realizados por órgãos públicos. Logicamente não será solução imediata para todos os problemas existentes, mas gradativamente exigirá uma maior profissionalização da indústria de TI e realizará melhor uso dos recursos governamentais.

Produtividade e projetos bem sucedidos: O que está faltando?

Por Roberto Argento (http://www.linkedin.com/in/robertoargento)

Há cerca de um mês deparei-me com o artigo de Joe Marasco: “Software development productivity and Project success rates: Are we attacking the right problem?” . Ele toca num assunto que havia chamado minha atenção durante várias sessões de “project assessments” que eu me dediquei em 2005. Durante o ano passado participei da avaliação de cerca de 14 projetos ou organizações de desenvolvimento em 6 países da América latina (México, Brasil, Chile, Argentina, Peru e Colômbia), em diversos setores da economia (finanças, seguros, telecom, software houses, órgão públicos, energia) e abrangendo diversas tecnologias. Do desenvolvimento Java ao mainframe, da criação de produtos de prateleira à manutenção de ERPs. Nesses diagnósticos dois aspectos se sobressaíram.

O primeiro deles está relacionado ao estágio de desenvolvimento que a indústria de software se encontra em nossa região. É interessante notar que não há diferenças significativas de maturidade entre os projetos dessa pequena amostra. Estamos todos mais ou menos com as mesmas questões e caminhando na mesma direção.

O outro aspecto está relacionado a um problema comum a todos os projetos analisados: levantamento de requisitos . Não importa o sintoma apresentado pela equipe: “Não conseguimos testar, os sistemas são muito voláteis” ou “Os usuários mudam de idéia muitas vezes” ou “Tudo muda o tempo todo”. O fato é que todos os projetos analisados usam técnicas muito primárias para levantamento de requisitos. É quase como se quisessem tirar esse “problema” da frente e começar a desenvolver. É esse ponto que gostaria de explorar um pouco mais.

O interessante é que quase todas as equipes possuem bons padrões de documentação de requisitos: especificações funcionais, modelos, planilhas, etc. Entretanto, praticamente todos os grupos usam apenas uma técnica de levantamento de requisitos. Muitos deles recebem as especificações escritas e as tomam como boas, sem um aprofundamento maior, seja do problema ou da solução. É quase como se uma testemunha fosse interrogada apenas pelo promotor ou pelo advogado de defesa, sem nenhuma verificação ou busca de contradições no seu depoimento.

O senhor Marasco coloca esse tema sobre outro ponto de vista. Ele apresenta um contraste entre o importante ganho de produtividade das equipes de nas últimas décadas e a relativa pequena melhora na taxa de êxito nos projetos. Segundo o Chaos Report , publicado desde 1994 pelo Standish Group, a taxa de sucesso em projetos passou de 16% em 94, para 28% em 2001 e 31% em 2003. Nesse ritmo, apenas em 2014 vamos conseguir fazer com que metade dos projetos de desenvolvimento tenha sucesso.

Joe Marasco defende a tese que estamos sendo muito bons em desenvolver novas soluções, mas pouco eficientes em levantar o problema correto e os requisitos corretos. Ou seja, fazemos mais rápido e com técnicas mais sofisticadas as soluções erradas.

A prática de gerência de requisitos nos ensina que devemos combinar várias técnicas para levantar e esclarecer os requisitos. Assim conseguiremos validar o que um grupo está nos dizendo, o reinquirindo de outras formas e/ou comparando suas repostas com as de outros grupos. Técnicas como entrevistas, questionários, workshops, brain storms, entre outras, são raramente usadas de forma combinada com esse propósito.

Nossa experiência tem mostrado que não basta o uso de técnicas como casos de uso e desenvolvimento iterativo ou o uso de ferramentas de gerência de requisitos que permitam controlá-los, acompanhar suas mudanças e manter a rastreabilidade entre eles e os demais artefatos de software. Tudo isso é importante e garante um ganho de produtividade significativo, mas o uso de técnicas mais sofisticadas de levantamento é chave para quebrarmos o ciclo de construir a aplicação que achamos ser correta, receber as críticas, tentar novamente,...

Muitas vezes o simples treinamento em conjunto dos analistas de negócio, usuários e o pessoal de sistemas nas técnicas corretas, como aquelas descritas no RUP , reduzem graves problemas de entendimento entre os dois grupos. Em outras, o uso de uma consultoria especializada pode ajudar à organização a reduzir o abismo entre as áreas, diminuindo o estresse e facilitando o sucesso coletivo.

Como um colega costuma dizer: “Os usuários sabem o que querem, mas em geral não sabem descrevê-lo! Mas quando o vêem sabem identificá-lo”. Somente com um trabalho sistemático de levantamento das necessidades de negócios, dos requisitos de software, das especificações funcionais e não-funcionais, suportado por ferramentas que possibilitem o gerenciamento e a colaboração é que poderemos levar nossas equipes de desenvolvimento a um novo patamar. O patamar de produtividade e qualidade que nossas organizações precisam para competir no mundo plano .

Referências:

“Software development productivity and Project sucess rates: Are we attacking the right problem?”, por Joe Marasco, CEO, Ravenflow:
http://www-128.ibm.com/developerworks/rational/library/feb06/marasco/index.html?ca=drs-#rate

“Requirements: An introduction” por Scott McEwen, Metasys Technologies, Inc.
http://www-128.ibm.com/developerworks/rational/library/4166.html

Para mais informações ver: http://www.standishgroup.com

“Dissecting business from software requirements” por Jochen Krebs:
http://www-128.ibm.com/developerworks/rational/library/aug05/krebs/index.html

RUP - Rational Unfied Process
http://www-128.ibm.com/developerworks/rational/products/rup

Por que utilizar uma Metodologia de Desenvolvimento de Sistemas

Por Roosevelt Benvindo de Oliveira

A informalidade em projetos de TI tornou-se um fator de fracasso em muitos projetos. Alguns estudos, como por exemplo, às pesquisas publicadas pelo Standish Group, revelam que a quantidade de projetos fora do prazo, custo ou até mesmo abandonados, está diminuindo através da adoção de metodologias de gerenciamento de projetos. No entanto, não basta somente gerenciar melhor os projetos. É preciso aliar o bom gerenciamento de projetos com a escolha da melhor solução metodológica, observando sempre a cultura organizacional da empresa.
Uma Metodologia de Desenvolvimento de Sistemas é composta por seqüências de atividades executadas de forma organizada, que visam à construção de um Sistema de Informação com qualidade, no prazo e custo determinados, deve ser adequada à organização, de forma a otimizar o desenvolvimento de sistemas sem, no entanto, burocratizar a execução das atividades. Por este motivo, uma MDS desenvolvida para uma organização é eficiente apenas para a organização que a gerou, tornando-se menos eficiente em outra organização. Outra característica importante é que ela deve ser mutável, ou seja, da mesma forma que uma organização muda ao longo do tempo, ela deve adequar-se às mudanças de forma a manter a produtividade e eficiência desejada.
Existem diversas abordagens de ciclo de vida de software nas quais podemos basear uma MDS. Podemos citar, dentre as principais, o modelo Cascata, Evolucionário, por Prototipação, Iterativo e Incremental, dentre outros. Cada abordagem de ciclo de vida possui vantagens e desvantagens que precisam ser observadas na elaboração. Por exemplo, para softwares que tenham os requisitos estáveis e imutáveis, a abordagem em Cascata é mais eficiente. No entanto, seria um desastre a adoção do mesmo modelo para softwares que tenham os requisitos instáveis e mutáveis. Isso reforça o conceito de que cada organização deva ter sua própria metodologia e que a mesma deve ser desenvolvida observando a cultura organizacional e a estrutura de desenvolvimento proposta na organização.
Existem várias metodologias, nas mais variadas abordagens de ciclo de vida, disponíveis no mercado. Podemos destacar, dentre as principais, o RUP, OPENUP, XP, SCRUM. Pode-se também, conforme o caso, fazer um misto entre metodologias, obtendo assim o melhor de cada metodologia envolvida.
Quando bem implantada, traz, entre outros, os seguintes benefícios:
· Independência de indivíduos e facilidade de manutenção: Como os sistemas são bem estruturados e têm documentação padronizada e atualizada, um analista consegue, em pouco tempo, dar manutenção em um sistema que não conhece, evitando a figura do “dono do sistema”, situação desvantajosa tanto para a organização quanto para o próprio analista.
· Aumento da produtividade: Sistemas bem construídos têm mais partes reutilizáveis.
· Um bom gerenciamento de projetos: Como as etapas e produtos estão bem definidos, é possível saber a cada momento como está o andamento do projeto.
Uma metodologia atinge seu objetivo se for prática, de fácil utilização, rápida aprendizagem e, na medida do possível, suportada por ferramentas que automatizem tarefas repetitivas e mantenham o trabalho organizado. Portanto quando bem desenvolvida e adaptada à organização é uma poderosa ferramenta para se alcançar maturidade em desenvolvimento de projetos de TI.

Guia de Certificações do PMI - PMP

Por Roosevelt Benvindo de Oliveira

Segue um roteiro com os primeiros passos necessários para se tirar a certificação PMP. Antes de tudo lembre-se: "Basta darmos um primeiro passo e já não estaremos mais no mesmo lugar!!!"

O Project Management Institute (PMI) é uma instituição sem fins lucrativos criada nos Estados Unidos em 1969 com a finalidade de promover avanços nas técnicas de gerenciamento de projetos através da qualificação profissional.Vivemos numa sociedade em que a competição e o rápido avanço tecnológico são realidades. Dessa maneira, se faz cada vez mais necessária a capacitação qualitativa dos profissionais dos diversos setores da economia. Pensando dessa maneira que o Project Management Institute vem promover essa capacitação. Hoje, essa organização é a única que possui seu processo de certificação não só reconhecido em todo mundo, como também pela International Organization for Standardization (ISO).

O Project Management Professional (PMP) foi criado em 1984 e hoje é o principal produto do PMI. Consiste na certificação da qualidade profissional individual promovida por esse instituto e reconhecida em todo o mundo, tanto no que diz respeito ao conhecimento quanto à experiência necessária ao bom desempenho da missão de gerenciar projetos.O Certified Associate in Project Management (CAPM) foi instituído em 2002 e amplamente revisado em 2004, e está voltado para praticantes de gerenciamento de projetos que demonstrem conhecimento fundamental em gerenciamento de projetos, que atuem sob a orientação de gerentes de projetos experientes, e que ainda não atendam aos requisitos de experiência na área que os qualifiquem para a certificação PMP. Vale ressaltar que as empresas vêm exigindo a certificação PMP e, com isso, a certificação CAPM não parece ser um bom caminho por uma questão de mercado.

O Que é o Processo de Certificação PMP?
O processo de certificação PMP consiste em uma pré-qualificação do candidato seguida de uma prova teórica sobre as áreas de conhecimentos em gerenciamento de projetos segundo o Guia PMBoK.

E porque se Certificar?
• Profissionalização do papel de gerência de projetos.
• Ampliação da empregabilidade do profissional;
• Reconhecimento do grau de qualificação atestado internacionalmente;
• Possibilidade de adicionar um aumento salarial médio acima de 10%;
• Segundo dados do próprio PMI, em torno de 61% dos empregadores reembolsam o exame de certificação e as taxas de preparação aos candidatos aprovados.

Requisitos para Certificação
Em linhas gerais o candidato precisa comprovar experiência em projetos equivalente a um mínimo de 4500 ou 7500 horas dependendo se é ou não formado em nível superior, além de educação na área de gerenciamento de projetos.

Para se certificar como PMP você precisará:
• Ter Background Educacional
• Comprovar Experiência na área através de:
1)Para quem tem nível superior: Comprovação de no mínimo 4.500 hs de atividades de liderança e direção em projetos. Essas atividades obrigatoriamente têm que ter ocorrido no período compreendido entre os últimos OITO anos;
2)Para quem tem nível médio: Comprovação de no mínimo 7.500 hs de atividades de liderança e direção em projetos. Essas atividades obrigatoriamente têm que ter ocorrido no período compreendido entre os últimos OITO anos.
• Mínimo de 35 horas de educação recebida específica na área de gerenciamento de projetos.
• Estar de acordo com o Código de Conduta Profissional do PMI.
• Pagar a taxa de inscrição; (US$405.00 para membros ou US$555.00 para os que não forem membros).
• Passar na prova de certificação.
Obs.: Quanto à comprovação das horas, o PMI atua exigindo que o candidato formalize (através de assinatura) que está sujeito às diretrizes de ética da entidade. No momento da submissão do pacote ele exige que, para cada projeto reportado, seja indicado um contato que possa verificar a experiência informada (deve ser preenchido um formulário por projeto -tantos quantos necessários para atingir o mínimo das horas, - 4500 ou 7500, conforme o caso.). Posteriormente, por um processo de amostragem, o PMI audita os pacotes submetidos. Se o candidato for auditado, receberá solicitações para que apresente comprovações das horas trabalhadas. Caso não consiga fazê-lo, estará passível de sanções definidas pelas Diretrizes de Ética do PMI. (Muita atenção a esta observação. Não invente projetos, pois esta auditoria realmente acontece e conheço pessoas que foram auditadas).

A taxa de inscrição para a prova é de US$ 405.00 para membros do PMI ou US$ 555.00 para os não membros. Recomendo fortemente que se associem ao PMI em virtude dos benefícios que vocês terão tais como o recebimento de publicações técnicas com artigos de interesse da comunidade de gerenciamento de projetos.

Vide comparativo:
Filiando-se ao PMI e ao capítulo de seu estado: Filiação ao PMI - Anuidade (US$ 119,00) + Filiação ao PMI – 1ª Inscrição (US$ 10,00) + Filiação ao capítulo DF (US$ 20,00) + Inscrição p/ Prova (US$ 405,00) = US$ 554,00
Sem filiar-se ao PMI: Inscrição p/ Prova (US$ 555,00) = US$ 555,00

Observamos que optando por se tornar membro do PMI, bem como do Capítulo, você obterá maiores benefícios em função do investimento realizado, revertendo para si, mais benefícios além do direito de realizar o exame, posto que você ainda economizará US$ 1.00. Além dos benefícios em tornar-se membro, você pagará US$ 100.00 a menos caso precise fazer o reexame, uma vez que a taxa de reexame é de US$ 275,00 para membros do PMI e US$ 375,00 para não membros. (Vale a pena pensar nisso!!)

Uma vez cumpridos os requisitos apresentados, você receberá uma carta de elegibilidade credenciando-o a se submeter a prova em um dos locais autorizados para tal. A carta de elegibilidade tem um ano de validade.

Etapas do Processo de Certificação PMP
1º - Qualificação:
Consiste na verificação por parte do PMI das informações submetidas para que seja avaliado se o candidato é ou não habilitado a prestar o exame teórico. Em caso afirmativo, será encaminhada ao candidato uma carta informando-lhe todos os dados necessários para a marcação da prova,informações sobre adiamento e cancelamento, número de elegibilidade que o identifique e permita o agendamento do exame, além de informações sobre o local e condições de realização do exame.
2º - O Exame
De posse dessas informações, o candidato entrará em contato com um dos centros de testes e assim efetuará a marcação de seu exame, através da informação de seu número de elegibilidade.Isso irá autorizá-lo a fazer a prova, indicando-o local e condições para fazer o exame de certificação.O exame é realizado on-line via computador, sendo o resultado informado imediatamente após o término da prova. Em Brasília, a casa Thomas Jefferson é o centro Prometric autorizado para o exame PMP.
O exame para PMP consiste de uma prova de múltipla escolha com 200 questões - com 4 opções de resposta cada - sobre toda a área de conhecimento compilada no PMBoK. O candidato tem um máximo de 4 horas para completar o teste. O teste é composto de 175 questões válidas para o exame e de 25 questões de validação, as quais estão ordenadas de forma aleatória.O percentual mínimo de acerto das questões da prova para garantir a qualificação do profissional deve ser de 60, 57%, representando 106 das 175 questões. Cada questão tem apenas 1 (uma) única resposta correta dentre quatro alternativas possíveis. Todas as questões têm o mesmo valor -> 1(um) ponto, independentemente de sua complexidade. Os assuntos são divididos percentualmente da seguinte maneira:

- 11% -> Iniciação;

- 23% -> Planejamento;

- 27% -> Execução;

- 21% -> Controle;

- 9% -> Fechamento;

- 9% -> Responsabilidade Profissional.

Acessem o site http://www.pmi.org/ para maiores informações e para iniciarem todo o processo.
Bem, compreender o processo de certificação PMP é o primeiro passo para iniciar a empreitada! Disponibilizarei nos próximos posts o material que utilizei para estudar para a prova.

Certificações Profissionais: Somente o PMP é suficiente?

Por José Eduardo Motta Garcia, PMP (jose.eduardo.garcia@gmail.com)

Vistas por muitos como caça-níqueis de empresas e instituições, as certificações profissionais, que há tempos fazem muito sucesso entre os profissionais de TI, também estão presentes no mundo do gerenciamento de projetos. E nesta área, a certificação PMP do PMI é, sem dúvida, a mais conhecida e desejada. A pergunta é: quais outras certificações seriam importantes, além do PMP?
Partindo do pressuposto de que conhecimento nunca é demais, muitos poderiam responder que qualquer uma, relacionada à área de atuação, seria importante. Porém, além da questão financeira, temos que lidar com um recurso limitado, não renovável e cada vez mais escasso – o tempo.
O próprio PMI lançou as certificações CAPM, voltada para profissionais de projetos em início de carreira, e a PgMP, para os gerentes de programas com grande experiência. Ambas, por motivos distintos, ainda não se popularizaram no Brasil. A CAPM enfrenta um problema de que o mercado exige o PMP, seja qual for o nível de atividade a ser realizada. Já a PgMP, além de ser mais recente, possui mais pré-requisitos e um rigoroso processo de avaliação, e não apenas um exame.
No Brasil, muitos gerentes de projetos são oriundos da área de TI. Com isso, algumas certificações mais voltadas à tecnologia são freqüentemente requisitadas, como o ITIL, para gerenciamento de serviços de TI, e o COBIT, para governança de TI alinhada ao negócio.
Para metodologias de gerenciamento de projetos há várias opções. Entre as principais, destaque para a PRINCE2, criada pelo governo britânico, cuja principal vantagem é a flexibilidade de adaptação a cada projeto, e que cresce a cada ano no Brasil com as certificações Foundation e Practitioner. A suíça IPMA (International Project Management Association), representada no Brasil pela ABGP (Associação Brasileira de Gerenciamento de Projetos), é a mais antiga associação mundial em gerenciamento de projetos e também possui seu programa de certificações, dividido em 4 níveis. Há ainda metodologias alternativas e não menos interessantes, como a da Scrum Alliance, para gerenciar projetos ágeis, que concede a certificação Scrum Master para quem conclui com sucesso seu treinamento oficial.
Com relação a ferramentas, também existem as certificações específicas para os principais sofwares utilizados na área de projetos. A IIL (International Institute for Learning) certifica profissionais em Microsoft Project, com os níveis White, Orange, Blue e Black Belt. O Primavera, outro software bastante utilizado, possui certificações para os níveis básico e avançado.
Em se tratando de melhoria de qualidade em processos, a Six Sigma, criada a partir de práticas ensinadas na Motorola University, reina absoluta em popularidade. Posteriormente foi incorporado o conceito Lean, que é dar foco no que realmente é essencial. Esta certificação também possui vários níveis e a fonte mais respeitada é a ASQ (American Society for Quality).
Outro assunto que freqüentemente está na pauta de discussões entre profissionais da área é o modelo de maturidade. Para se montar um PMO, por exemplo, é quase inevitável utilizar um. O PMI possui o OPM3, e as certificações são para Assessor e Consultant. O mais utilizado, CMMI, também possui treinamentos oficiais no Brasil, reconhecidos pela SEI (Software Engineering Institute). Uma opção 100% brasileira é o MPS.Br, da SOFTEX, com as certificações de introdução, implementadores, avaliadores e de melhoria de processos.
Não há dúvidas que a certificação PMP é o primeiro grande objetivo de um gerente de projetos, porém a continuidade torna-se cada vez mais necessária. As alternativas são as mais variadas possíveis, e a área de atuação pode ajudar a definir o caminho. Buscar uma certificação de outra metodologia de gerenciamento de projetos e outra de modelo de maturidade tendem a ser opções interessantes.
Sobre o futuro, se eu fosse apostar em uma certificação promissora para a área de projetos, inovaria e colocaria minhas fichas na LEED Accredited Professional, da GBCI (Green Building Certification Institute), pois o conceito de sustentabilidade e a preocupação com o meio ambiente são cada vez mais evidentes na implantação de novos projetos, seja qual for o ramo de atividade da empresa.
Muitos defendem que o importante é apenas possuir o conhecimento e saber colocá-lo em prática, e que a certificação é dispensável. É claro que profissionais que se limitam apenas à teoria tendem a fazer sucesso apenas na área acadêmica, porém como provar ao mercado que se realmente conhece o assunto? Mas essa é outra discussão...