Introdução.

Os PMOs ou Escritórios de Gerenciamento de Projetos estão sendo impelidos a gerenciar as áreas de negócio que não têm sido tradicionalmente envolvidas com projetos e tem recebido a tarefa de equilibrar a demanda e gestão de valor pelas organizações. O gerenciamento de projetos, programas e portfólios já está sob a responsabilidade da maioria dos PMOs e já há um grande alinhamento entre os projetos e as estratégias das empresas, o que demonstra que o PMO tem se tornado um agente de mudanças nas organizações nos últimos anos.

O grande diferencial oferecido pelos Escritórios de Projetos é garantir crescimento através do planejamento e execução de projetos bem sucedidos, mantendo uma equipe enxuta, aliada a abordagens flexíveis que se adaptam a mudanças de cenários garantindo as entregas previstas, tendo um papel mais estratégico com apoio executivo e tornando o gerenciamento de projetos mais consistente, mensurável e eficaz, sem deixar de usar abordagens adaptativas  para equilibrar o portfólio, através de inovação e compromissos operacionais.

O papel do PMO nas organizações.

O papel da grande maioria dos PMOs é o de integrar e apoiar as atividades de gerenciamento de projetos, através da priorização, análise de informações, status de projetos e apoio na tomada de decisões assertivas, além de aliviar a sobrecarga de atividades dos gerentes de projetos, devendo também colaborar para agregação de valor e estabelecimento de metodologias de gerenciamento de projeto, centralização de informações estratégicas, monitoramento de cronogramas, status, orçamentos, evolução de projetos, conclusão dos mesmos, mensuração dos resultados obtidos e apresentação e tais resultados aos executivos seniores das corporações.

Cabe ao PMO também, ser o principal ponto de referência para os intervenientes, gerentes e times de projetos, dar a devida priorização das propostas que serão convertidas em projetos, dispor e garantir os recursos necessários para cada projeto, garantir a capacitação de profissionais em conceitos e boas práticas de gerenciamento de projetos, controlar os padrões de qualidade estabelecidos, aconselhar os gerentes de projetos e dar feedback aos executivos e sponsors.

Outrora conhecido como um organismo extremamente burocrático pela grande exigência de formalização, padronização e documentação de todas as ações, tem sido desafiado a agir com mais flexibilidade e fluidez de acordo com cada tipo de projeto, para alcançar inovação das boas práticas e com isso maximizar os resultados alcançados e entregues.

Dentro de seu papel nas organizações os PMOs enveredaram por caminhos diferentes, em especial devido ao grande modelo de gestão disponível nas mais diversas organizações e começaram a se diferenciar o que evidenciou níveis de maturidade bastante específicos para os mais diversos PMOs pelo mundo.

PMO e seus níveis de maturidade.

Quanto mais maduro for o PMO e melhor discutida a priorização da carteira de projetos que serão executados, mais empatia o PMO terá da alta administração e é um desafio estabelecer uma rede de apoio entre os participantes do projeto para criar consistência nas práticas diárias e ganhar credibilidade com os parceiros de negócios céticos
utilizando manobras políticas relacionadas ao valor agregado que será entregue.

Para se ter idéia da relevância dos níveis de maturidade dos Escritórios de Projeto pelo mundo há inclusive modelos de avaliação de maturidade exclusivos para os PMOs. Tratam-se de iniciativas que tem contribuído bastante para a auto-avaliação, melhoria contínua, manutenção e perenidade dos mais diversos Escritórios de Projetos. Algumas dessas iniciativas têm foco muito mais abrangente do que os parâmetros que citamos neste artigo, e por este motivo alguns deles estão sendo amplamente utilizados.

Destacam-se, portanto, algumas características de 3 níveis de maturidade de PMOs, que passamos a considerar:

PMO de Baixa maturidade

• Os projetos não são sempre alinhados com a estratégia;
• O desempenho é muitas vezes precário;
• Prioriza desafios;
• Nem sempre é possível medir valor do projeto pós-execução.

Organizações que iniciaram um PMO há pouco tempo, que estão se adaptando às boas práticas de projetos, que estão engatinhando na criação e/ou adoção de uma metodologia para o gerenciamento de seus projetos, normalmente tem um PMO de baixa maturidade.

O principal foco destes PMOs está relacionado diretamente com a execução dos projetos e com a criação de uma cultura voltada para projetos na organização. Nestas situações as organizações e este PMOs encaram projetos como desafios do negócio e com grande foco em controles pra garantir a execução dos mesmos.

A partir destes primeiros passos este PMO ganhará experiência em gerenciamento de projetos para um processo de transformação que poderá levá-lo ao segundo nível de maturidade.

PMO de Maturidade moderada

• Prioriza projetos de alta visibilidade;
• Alguns projetos estão alinhados com a estratégia;
• Tem projetos de melhoria de desempenho.

Organizações que atingiram nível de maturidade moderada lutam duramente para oferecer conexões práticas entre a burocracia exigida pela alta necessidade de formalização e as práticas de execução e inovação que dão mais visibilidade aos projetos. Essa situação é bastante crítica e a sustentação e o crescimento dos PMOs depende da moderação dessas iniciativas que deve ter grande enfoque inter-organizacional. Obviamente os PMOs devem ter condições de distinguir entre o envolvimento dos Diretores e VPs que exercerão os papéis de patrocinadores dos projetos, o envolvimento de Gerentes e Coordenadores de áreas de negócio que exercerão o papel de agentes táticos e até o envolvimento de pessoas da operação que exercerão o papel de recursos diretos dos projetos.

Esta experiência em gerenciamento de projetos em todos os níveis da organização demonstrará ao board que as iniciativas são maduras e consistentes e que estão comprometidas com a eficiência e alto desempenho nos resultados obtidos com os projetos desde a escolha ou priorização dos projetos, quando são analisadas as informações relativas à contribuição que cada projeto dará ao negócio e quão alinhado cada projeto está com os objetivos estratégicos da organização.

É bastante provável que estes PMOs que estão em nível de maturidade moderada estejam concentrados em práticas de otimização, buscando total alinhamento com a governança corporativa, encontrando e retirando redundâncias e duplicidades dos processos, elaborando padrões de comunicação, aumentando a produtividade, além de estar desenvolvendo métricas e padrões de qualidade aderentes aos projetos que estão sob sua responsabilidade. Essas iniciativas alavancarão esses PMOs para o próximo nível.

PMO de Alta maturidade

• Gestão de portfólio, programas e projetos;
• A maioria dos projetos está alinhada com a estratégia;
• A metodologia é flexível e definida a cada projeto;
• Tem métricas de desempenho para todos os projetos;
• Há forte incentivo à otimização do desempenho.

Neste nível é fundamental tornar o PMO totalmente adaptável, ou seja, manter o rigor necessário e agregar criatividade e melhorar a performance, pois os ciclos de negócios estão cada dia mais dinâmicos e raramente permitem que possamos ficar muito tempo utilizando a mesma abordagem ou retroagir para abordagens passadas. As necessidades de cada projeto são diferentes e cabe ao PMO apoiar cada abordagem ressaltando as peculiaridades de cada projeto e criando abordagens adaptadas aos cenários que são distintos.

PMO e suas principais abordagens.

Quando ressaltamos que os PMOs devem ser adaptáveis, devemos ter em mente o quão adaptável cada PMO pode ser e para determinar esse horizonte é muito importante que fique evidenciada a real abordagem de cada PMO e para isso podemos separar os PMOs por tipos de abordagens, a saber:

 PMO Tático.

Tem foco em projetos que entregam muitos benefícios, mas que demandam um alto risco. O trabalho é realizado como apoio para entrega de projetos, integrando metodologia de gerenciamento de projetos em atividades específicas. Desse tipo de PMO não se espera resultados estratégicos e suas entregas normalmente não influenciam diretamente nos objetivos estratégicos das empresas, ou se influenciam, isso ocorre indiretamente.

O principal objetivo de um PMO tático é a entrega e utiliza-se fundamentalmente de ferramentas que comunicam e compartilham informações de projetos.

O PMO tático tem suas responsabilidades e papéis claramente definidos de forma bastante tradicional e estática. Um bom exemplo é que um determinado recurso pode participar de vários projetos, mas sempre assumirá o mesmo papel. Se um recurso participar de cinco projetos diferentes em todos eles ele assumirá o mesmo papel, por exemplo, atuando como programador e suas responsabilidades nestes cinco projetos serão sempre muito parecidas.

Ainda, podemos exemplificar que PMOs que tenham abordagem tática, tendem a atender unicamente uma área de negócio específica, por exemplo, há PMOs de empresas que cuidam apenas de projetos de software e esses PMOs se envolvem somente nesses projetos. Caso essa empresa tenha uma estratégia de construir um novo prédio, mais amplo, e embora para a estratégia da empresa esse seja um projeto singular o PMO dessa empresa não participará ativamente desse projeto.

Algumas características do PMO Tático:

• Foco em projetos;
• Metodologia baseada na execução dos projetos;
• Ênfase em ferramentas, governança de projetos e relatórios de status;
• Estilo de gerenciamento focado em controles;
• Projetos são estáticos;
• PMO se reporta a diretoria;

PMO Estratégico.

O PMO estratégico, como o próprio nome já diz, tem uma abordagem estratégica nas empresas e com isso uma visão holística dos processos de negócio das organizações. Eles agregam ao PMO tático muitas outras características importantes, como por exemplo, o fato de terem maior maturidade, apoio da alta direção das suas organizações, práticas consistentes de gestão para todos os projetos, direcionamento de decisões importantes e reconhecimento do bom planejamento e execução dos trabalhos.

Esse tipo de PMO tem desafios mais consistentes como, por exemplo, integrar o planejamento estratégico com as entregas de cada projeto, para que dessa forma, cada entrega de cada projeto do portfólio gere uma contribuição direta aos objetivos estratégicos da companhia.

 As organizações com PMOs estratégicos integram ferramentas de gestão de projetos, medições de performance e desempenho com metodologias desenhadas especificamente para o objetivo fim de cada tipo de projeto, podendo receber apoio direto das áreas de TI que influenciam diretamente nos trabalhos do PMO, dando dinamismo nas soluções requeridas. É importante, também, que esse tipo de PMO esteja menos preocupado com estruturas das organizações ou com questões burocráticas, e que não permita que padronizações retardem os processos ou impeçam a capacidade de reação e adaptação de cenários, que são fundamentais para esse tipo de PMO.

Algumas características do PMO Estratégico:

• Tem foco em planejamento estratégico dos projetos e agregação de valor;
• Metodologia baseada em ciclos de vida de projetos adaptáveis;
• Ênfase em ferramentas, governança de projetos corporativos, gestão de riscos e conformidades;
• Estilo de gerenciamento visa colaboração e supervisão da carteira de projetos
• Projetos são adaptáveis;
• PMO se reporta à vice-presidência ou presidência;

PMO como agente de mudanças nas organizações.

Empresas comprometidas com uma abordagem holística para a gestão de portfólio, programas  e projetos devem construir uma abordagem global de seus projetos. Isso não quer dizer que cada projeto não possa ter suas especificidades, mas é muito importante que as questões globais estejam claramente definidas.

Para se tornar um agente de mudanças nas organizações, os nossos PMOs precisam:

• Construir uma vigorosa demanda.

O PMO deve ajudar a consolidar a demanda, captando as propostas de projetos das mais diversas áreas de negócios, permitindo que os sponsors saibam da existência de todos os projetos do portfólio, para que a demanda seja conhecida por todos, o que ajudará no processo de priorização. É papel fundamental do PMO tornar claro aos sponsors as ferramentas que necessita para que toda a empresa conheça o portfólio e que todos possam propor projetos que serão analisados quanto à viabilidade e quanto ao alinhamento estratégico, devendo essa informação ter os níveis adequados de acesso onde alguns colaboradores terão visões bastante analíticas e outros terão visões estritamente sintéticas, como por exemplo os resultados de alguns poucos indicadores globais definidos como estratégicos para a gestão do portfólio.

• Ter um consistente processo de priorização da carteira de projetos.

O processo de priorização deve ser maduro e deve usar ferramentas que ajudem a organização a ver como o atendimento de determinados projetos impactará de forma favorável aos objetivos estratégicos. Esse processo depende da existência de uma carteira centralizada de projetos e propostas, que deve ser gerenciada pelo PMO, para que eventuais mudanças possam ser analisadas de forma integrada, quanto ao tamanho da mudança, impacto em previsões já estabelecidas e resultados que precisam ser alcançados. É através desse processo que as discussões de prioridades tornam-se mais consistentes e eficazes.

• Ter patrocinadores que apóiem as mudanças necessárias.

O PMO deve ter apoio da alta direção para conseguir colocar em prática mudanças nas organizações. O desafio de manter uma carteira única de projetos, de opinar nas mudanças, de manter todos da companhia informados quanto aos status dos projetos, de definir e apresentar indicadores de projetos e sobretudo de conhecer os detalhes estratégicos do negócio dependem em muito de um sponsor que compreenda a atuação do PMO, que entenda a necessidade de tornar as decisões mais globais e do apoio que esse sponsor dará ao PMO para que suas atividades sejam consolidadas na organização.

Não são poucas as barreiras que se apresentam quando um PMO passa a ter atuação estratégica, mas é um processo necessário para que as empresas possam impulsionar as mudanças. Para esse cenário é fundamental um estreitamento entre o PMO e a alta direção para assegurar autoridade para impor mudanças necessárias, bem como atribuir responsabilidades e definir boas práticas.

• Usar medidas apropriadas para acompanhar os projetos e garantir apoio da alta direção.

Selecionando indicadores adequados o PMO pode demonstrar que a organização está atingindo seus objetivos ou que está em risco em algum aspecto relevante ao planejamento estratégico, que envolvam decisões que levem a alterações de curso dos projetos, que afetem os custos estimados, prazos de entrega ou qualidade das entregas.

Medidas como custo e cronograma serão sempre parte integrante dos processos de gerenciamento do PMO, assim como medidas de qualidade, e ainda podemos elencar  medidas como redução de trabalho, níveis de alocação de recursos e satisfação dos stakeholders para evidenciar os progressos do gerenciamento dos projetos.

• Criar um plano de carreira para os gestores de projetos.

Não podemos nos esquecer de que é fundamental considerar que os gestores e equipes de projetos perseguem alvos profissionais muito sólidos. Por estarem expostos a questões estratégicas, almejam largamente um avanço profissional motivado pelas constantes conquistas e agregação de valor ao negócio que os resultados obtidos geram.

Diante disso, as organizações com PMOs com atuação estratégica não podem perder de vista um plano de carreira formatado especificamente para esses profissionais.

Conclusão.

Embora todos os CEOs e CFOs desejem PMOs estratégicos nem todas as organizações estão preparadas para esse modelo de atuação e é fundamental considerar que um PMO pode atuar como um grande agente de mudanças em sua organização em especial quando este busca o aprimoramento e a excelência e também conhece exatamente o ponto em que está (auto-avaliação) e o ponto em que deseja atuar.

É preciso também ter em mente que para que seu PMO atue como agente de mudanças em sua organização ele precisará ser um elo de ligação entre os objetivos do negócio e a camada de projetos desenvolvendo mecanismos para a evolução.

Fundamentalmente as transformações e evoluções do PMO não devem ser traumáticas e devem alcançar resultados positivos numa crescente quebra de paradigmas, melhoria dos processos e evolução de equipes e pessoas.

Autor: Samuel Gonsales é diretor da Kayros IT Consultoria, especializada em modelos de gestão para empresas de moda e vestuário. samuel@kayros-it.com.br
É analista de sistemas pela Universidade Paulista e tem MBA em Sistema de Gestão Empresarial ERP e Gestão de Negócios pela FIAP. Atua também como professor para graduação e pós-graduação, palestrante e articulista de jornais, revistas e portais de negócio e tecnologia.

Artigos Relacionados:

1. As 10+ funções de um PMO
2. A Importância da Flexibilidade em PMOs
3. Benchmarking em Gerenciamento de Projetos: PMO e Treinamento

“Apesar do desenvolvimento e disseminação cada vez mais ampla das técnicas e ferramentas do PMBOK, o nível geral de sucesso em projetos ainda não corresponde às justas expectativas de seus clientes e patrocinadores. Não se questiona a efetividade das técnicas e ferramentas de gerenciamento de projetos compiladas pelo PMI e por outras organizações. Porém, o fato é que os bons resultados só acontecem quando aplicamos essas técnicas adequadamente. E para aplicar adequadamente não basta conhecê-las. Um gerente competente precisa ser capaz de conduzir efetivamente as atividades, enfrentar e resolver as situações práticas do dia a dia dos seus projetos. E para isto precisa desenvolver as competências necessárias”, avalia Varella. Saber quais são essas situações típicas de conflitos em projetos foi um dos grandes objetivos da pesquisa. “A competência do gerente para lidar com estas situações e resolvê-las é o diferencial que leva à aplicação mais adequada das melhores práticas, aos melhores resultados e a um índice mais elevado de realização, satisfação e sucesso”, destaca Varella.

A obtenção de resultados satisfatórios e coerentes depende fundamentalmente do método utilizado na condução da pesquisa. Nesse caso o trabalho foi dividido em duas fases. “A etapa inicial tinha o propósito de identificar as situações típicas. A seguinte visa ampliar e consolidar esse quadro de situações”, diz Varella. Na primeira etapa foram consultados oitenta profissionais considerados experts em gerenciamento de projetos. Eles foram solicitados a citar duas situações típicas de conflito em projetos, para cada uma das fases do ciclo de vida, divididas em iniciação, planejamento, execução e controle e encerramento. A fase seguinte procurou validar a lista de situações mais presentes identificadas na primeira etapa, com a diferença que o público foi ampliado para 456 pessoas divididas entre 13 capítulos do PMI no Brasil. Os participantes dessa segunda fase também tiveram a possibilidade de incluir novas situações de conflito que julgassem importantes. “Menos de trinta situações adicionais foram sugeridas. Todas aquelas descritas se encaixaram e puderam ser classificadas em algum dos 104 tipos definidos na etapa inicial. Isso indica que a identificação promovida pelos experts na etapa inicial foi bem sucedida, abrangente e consistente”, diz Varella. O resultado final não significa que o trabalho se encerrou; muitos estudos e comparações ainda devem ser desenvolvidos com os dados coletados. “Uma ampla gama de análises individuais e comparativas pode ser feita com base nos relatórios regionais e no consolidado. Acredito que neste ano de 2011 conseguimos um grande avanço na obtenção de informações e conhecimento sobre o tema”, avalia Varella.

Qualquer projeto é conduzido por uma equipe, da qual o gerente de projeto faz parte. A capacitação dos demais membros do time normalmente é mais especialista, de acordo com cada perfil de pessoa e de projeto. Em geral, a responsabilidade sobre a gestão do projeto recai totalmente sobre o gerente. Com certeza essa é uma das razões que levam ao insucesso: equipes sem qualificação adequada para trabalhar em ambientes de projeto. Claro que a responsabilidade maior deve realmente ser do gerente de projeto, mas contar com pessoas capazes de compreender seus papéis e os elementos fundamentais envolvidos (tempo, custo, escopo, riscos, por exemplo) é de extrema importância. A certificação CAPM oferecida pelo PMI visa exatamente credenciar membros de equipe que, além de suas funções especilistas, também querem e precisam conhecer um pouco sobre gerenciamento de projetos. “Acredito que as certificações CAPM e PMP são igualmente necessárias e que a quantidade de profissionais CAPM precisa ser maior do que a de profissionais PMP. O gerente de um projeto precisa de uma equipe capacitada. Uma equipe de CAPMs liderada por um PMP certamente alcançará melhor desempenho gerencial e elevará as chances de sucesso do projeto. Creio que é necessário um trabalho institucional mais intenso e sistemático de divulgação, esclarecimento e valorização da certificação CAPM”, diz Varella.

A pesquisa pode comprovar a presença de algumas situações de conflito certamente bastante conhecidas no cotidiano de quem lida diariamente com pessoas e projetos. A gestão de mudanças, por exemplo, foi apontada com principal fonte de conflitos na fase de execução. Saber como lidar com as mudanças ainda é um grande desafio. “Riscos e mudanças são as duas únicas certezas que temos em todos os projetos. O aprimoramento das competências necessárias para uma atuação gerencial pró-ativa e não reativa, que permita ao gerente do projeto elevar o seu nível de influência sobre os riscos e sobre as mudanças é uma grande oportunidade para melhorar o seu desempenho e os resultados dos projetos”, conclui Varella. A pesquisa também revela um forte relacionamento entre os conflitos apontados. Muitos são consequência de outros que, não tratados de forma correta, acabam gerando novos problemas no futuro. Obter estimativas coerentes, por exemplo, foi eleito o principal fator de conflitos da fase de planejamento. Com certeza um escopo melhor definido ajudaria bastante nesse aspecto. “Esse é um exemplo de reação em cadeia, uma seqüência de causa-e-efeito. Para atuar de forma efetiva caminhando progressivamente para o sucesso final, o gerente precisa enfrentar e resolver passo a passo estas situações. Cada situação mal resolvida implica em um problema mais adiante”, diz Varella. Por fim, na fase de encerramento a principal fonte de problemas concentra-se no registro das lições aprendidas. “Em geral, faz-se uma associação indevida de lições aprendidas com algo que já passou e que, quem sabe, pode ser útil no próximo projeto. Mas quando podem ser mais úteis as lições aprendidas de projetos anteriores senão no início do seu projeto atual? Além da disciplina também há uma questão de cultura”, avalia Varella.

Conhecer as próprias dificuldades é o primeiro passo em direção da solução. Dessa forma o trabalho realizado pretende contribuir para a maturidade do gerenciamento de projetos no país. “Tem sido gratificante receber o feedback de vários colegas que já estão utilizando os relatórios e as informações em suas atividades, estudos, aulas etc. O aprimoramento é um processo contínuo. Estamos sempre aprendendo; e podemos aprender muito mais avançando na obtenção e refinamento de informações. Nossa intenção é servir, compartilhar e contribuir para o desenvolvimento de conhecimentos, o avanço no domínio das práticas e a melhoria do desempenho em projetos”, conclui Varella.

Sobre o entrevistado: Lelio Varella, PMP é chairman da consultoria P&M ProActive, ex-presidente do Capítulo Rio do PMI e autor do livro “Aprimorando Competências de Gerente de Projetos”, publicado pela editora Brasport.

Fonte: E-news do PMI-SP

1. Valores

1.1. Comunicação

A comunicação é o ponto chave em qualquer metodologia de gerenciamento de projeto para se alcançar o sucesso. A característica da metodologia “XP” com relação à comunicação é o envolvimento dos usuários, de tal forma que praticamente se tornam membros da equipe de desenvolvimento, aproximando-se aos desenvolvedores e possibilitando acesso as informações de forma rápida. Uma característica desta metodologia é o número de pessoas, onde quanto maior a quantidade, maior a dificuldade em gerenciá-las.

1.2. Simplicidade

Uma maneira importante de se abordar a simplicidade da metodologia “XP” é o tempo empregado no desenvolvimento de software. Em outras metodologias, grande parte é desperdiçada, onde ao menos 20% do que é desenvolvido é realmente utilizado. Os princípios do “XP” seguem a linha que funcionalidades extras aumentam a complexidade e não a flexibilidade, e o foco é desenvolver apenas o que o cliente realmente solicitou.

1.3. Feedback

Funciona em mão dupla, do cliente para o desenvolvedor e vice-versa. O cliente é quem alimenta a equipe de desenvolvimento com suas reais necessidades, estabelecendo prioridades e demonstrando suas reais intenções com relação ao produto final. O desenvolvedor informa de maneira constante e realista, os riscos e estimativas.

O “XP” detém uma importante característica de Feedback, onde a organização de ciclos curtos, possibilita aos clientes um melhor acompanhamento do projeto e suas funcionalidades, inclusive com partes do projeto funcionando. O desenvolvedor só passará para próxima fase, se as funcionalidades forem aprovadas pelo cliente.

1.4. Coragem

Os desenvolvedores e os clientes temem sempre que algo ruim possa acontecer, impossibilitando assim, possíveis resultados melhores. As principais “assombrações” dos desenvolvedores são:

• Não receber definições claras sobre o que precisa ser feito;
• Sacrificar a qualidade devido ao prazo.

Em contrapartida, os clientes também têm preocupações como:

• Não obter o que esperavam;
• Requisitar produtos que não serão utilizados.

Como no Feedback, uma das técnicas mais utilizadas são as iterações curtas, onde o cliente deve sempre estar próximo ao desenvolvimento.

2. Principais Práticas

2.1. Clientes Presentes

A presença do cliente no ciclo de desenvolvimento contribui para o Feedback de melhor qualidade entre cliente e desenvolvedor. Permite realizar pequenas mudanças não deixando aumentar os requisitos do cliente. Outro ponto essencial com essa proximidade é o desaparecimento de temores, tanto de clientes quanto de desenvolvedores.

2.2. Planejamento

O planejamento no “XP” é muito iterativo, ou seja, realizado várias vezes. Neste momento o cliente solicita novas funcionalidades e a equipe estima o custo de cada uma delas planejando as iterações.

2.3. Stand Up Meeting

No inicio da manhã é realizada uma breve reunião onde a equipe será atualizada das funcionalidades realizadas no dia anterior e definem-se prioridades para o dia que se inicia. Com essas atitudes há uma aproximação dos desenvolvedores diminuindo contradições ao longo do projeto.

2.4. Releases Curtos

É um conjunto de funcionalidades que representam valores ao cliente. O recomendável nesta metodologia, é que pequenas entregas sejam feitas ao cliente ao longo do projeto, onde assim ele pode começar a usufruir dos produtos do projeto, ao contrário de metodologias tradicionais onde o cliente aguarda até o fim para utilizar os produtos.

3. Conclusão

A metodologia “XP” é típica para ser utilizada em ambientes de desenvolvimento de sistemas. Ao longo dos anos, essa metodologia vêem ganhando força por ser uma metodologia ágil seguindo a linha de fácil aplicabilidade.

Autor: Leonardo Anselmo
Fonte: E-news do PMI-SP

Referências utilizadas:

Wikipedia “Extreme Programming”. Disponível em: http://en.wikipedia.org/wiki/Extreme_Programming

Artigos Relacionados:

1. Evento em desenvolvimento ágil de software – “CAIPIRA ÁGIL”
2. Na Busca por uma Definição para o Termo “Gerenciamento Ágil de Projetos”

Os projetos de melhoria conduzidos dentro do Programa Lean Seis Sigma devem ser feitos em equipe, sob a liderança de um especialista na metodologia e nas ferramentas estatísticas e de qualidade propostas no Programa. Esses especialistas são normalmente chamados de Green e Black Belts. Ao serem convidados a entrar no Programa, estes recebem uma formação que os capacita a conduzir os projetos. No entanto, percebe-se que algumas vezes os indicados para o curso de Green e de Black Belts não têm o perfil adequado para conduzirem um Projeto Lean Seis Sigma, o que acaba comprometendo o seu êxito. É bom ressaltar que isto não significa que eles sejam maus profissionais, já que há uma diversidade grande de perfis de profissionais e nem todos são recomendados para conduzir este tipo de projeto.

Nas primeiras empresas que implantaram o Programa Lean Seis Sigma, até por não terem claro o que esperar destes profissionais, era comum que as indicações fossem feitas como “prêmio” a alguns colaboradores, ou como forma de completar a carga de trabalho dos profissionais que estavam ociosos. Porém, estas empresas logo perceberam que as escolhas não poderiam ser feitas desta forma, pois vários projetos não chegavam ao seu final com sucesso. Ficou claro para estas empresas que, para ser um bom Green ou Black Belt,era necessário que os especialistas tivessem um perfil técnico e comportamental específico e que, além disso, tivesse tempo para conduzir suas análises.

Em relação ao perfil técnico, é esperado que um Belt tenha um raciocínio analítico bem desenvolvido, que consiga dar uma ordem lógica ao seu raciocínio e que saiba conduzir projetos (todo projeto tem começo, meio e fim). Além disto, alguma facilidade com números também é necessária, pois as ferramentas estatísticas são bastante utilizadas. Conhecer tecnicamente o assunto cujo projeto irá desenvolver ajuda, mas não é o mais importante. As características anteriores são necessárias, e esta última é recomendada.

Tratando do perfil comportamental, como um Belt irá conduzir projetos funcionais ou multifuncionais que sempre envolverá outras pessoas, é recomendado que um Belt saiba trabalhar em equipe, tenha uma boa capacidade de comunicação, iniciativa, poder de argumentação, curiosidade, perseverança e bom trânsito na empresa. Durante a condução do projeto, muitas serão as barreiras encontradas. O que se espera de um bom Belt é que, quando se deparar com uma, ele consiga rapidamente encontrar a solução, para que não fique com o projeto parado ou até desista dele.

Uma terceira questão relacionada ao perfil dos especialistas é o fato de que ele precisará de tempo para fazer suas análises e conduzir o projeto com sucesso. Normalmente um gerente da empresa tem um bom perfil técnico e comportamental, mas quando ele é indicado ao curso de formação, normalmente falta-lhe tempo para conduzir o projeto, o que acaba ocasionando um insucesso. O mesmo vale para excelentes especialistas que estão com sobrecarga de trabalho. Por mais que eles tenham perfil técnico e comportamental interessantes, não conseguirão conduzir os projetos com a qualidade esperada.

Portanto, após dez anos implantando o Programa Lean Seis Sigma em grandes e médias empresas, posso afirmar que uma boa parcela do sucesso dos projetos de melhoria vem da indicação correta dos especialistas. Para isto, os gestores devem ter em mente que, de uma maneira resumida, os indicados devem ter um raciocínio lógico bem desenvolvido, assim como um alto“coeficiente de viração próprio” (capacidade da pessoa de sair de situações difíceis). Como peso para a indicação, a experiência mostra também que o perfil comportamental é mais importante que o técnico, até porque este é mais rápido de ser desenvolvido do que aquele. A sugestão para avaliar o perfil dos indicados é pedir auxílio à área de recursos humanos da empresa ou até, se for o caso, contar com ajuda de consultorias especializadas em análise de perfil.

Por fim, não basta somente indicar o especialista que tenha um bom perfil pessoal. O gestor deve se conscientizar de que, uma vez feita a indicação, ele deve proporcionar ao seu indicado que ele tenha tempo para conduzir o projeto. Desta forma, nem sempre o colaborador com o melhor perfil deve ser indicado para a turma que irá iniciar. É preferível um especialista com o perfil adequado e com horas livres para o projeto do que um com um perfil excelente mas com o seu tempo todo tomado por outras tarefas.

Autor: George Bratti é Gerente-sênior da OThink Soluções Empresariais

Mestre em Engenharia de Produção pela UFSC, engenheiro elétrico e contador ela Univille. Tem experiência como Engenheiro de Qualidade na Whirlpool por 4 anos e atuação como Consultor Master Black Belt desde 2002, tendo treinado mais de 20 Master Black Belts e 1000 Green Belts e Black Belts em grandes empresas como Nestlé, Votorantim Cimentos, Nokia, entre outras. Atuou na Índia e América Latina conduzindo trabalhos relacionados à qualidade no projeto de desenvolvimento de produtos

Em um primeiro momento esse tema parece soar sem importância, como se fosse apenas mais uma definição teórica e puramente conceitual, mas é a base para o fracasso real de inúmeros Projetos.

No Brasil e, principalmente, no setor corporativo privado, Projetos são erroneamente definidos como Programas apenas por serem grandes. Mas tamanho é simplesmente a consequência, e não o motivo para um Programa existir.

Outras justificativas usadas para transformar conjuntos de Projetos em Programa são o aproveitamento da dinâmica comum de vários recursos e a existência de inúmeras frentes de trabalho com mais de um time. Realmente Programas possuem essas características, mas apenas como consequência de um fator maior: a concepção de uma idéia geradora de um benefício estratégico, dando origem a um conjunto de iniciativas independentes responsáveis por concretizar o benefício idealizado. 

Um Programa, antes de se tornar um conjunto de projetos, nasce como uma idéia estratégica geradora de um benefício singular, sem a real certeza de que virá a se tornar dois, cinco ou dezenas de Projetos independentes. No momento de concepção do Programa, não sabemos ao certo o que deve ser feito para atingir o benefício idealizado, tampouco como fazer. Sabemos apenas que uma série de tarefas independentes gerará um benefício estratégico e único. E é comum um Programa, em plena execução, ainda gerar novos Projetos com o intuito de consolidar o benefício estratégico definido anteriormente.

Por sua vez, Projeto é um esforço pontual, menos abstrato. Por mais que um Projeto em sua fase de iniciação possua indefinição de escopo, tempo e custo, sempre temos em mente o principal entregável. Sabemos o “o que”. Apenas não sabemos ainda o “como”. E nesse contexto, para diferenciar um Projeto de um Programa, não importa o tempo, o custo e nem a quantidade ou interação entre os recursos.

Parafraseando o PMBoK (Project Management Body of Knowledge), do PMI (Project Management Institute), Projeto é um empreendimento temporário, com recursos limitados, que gera um resultado, produto ou serviço único. Já Programa é um conjunto de Projetos independentes que estão unidos e associados estrategicamente para geração de um benefício. Em um Programa, obviamente cada projeto possui um benefício próprio, afinal são independentes. Mas o benefício gerado pelo Programa é diferente dos benefícios individuais de cada Projeto. E esse benefício do Programa é geralmente pensado primeiramente e estrategicamente antes de ser criado o conjunto de Projetos.

Como exemplo, podemos citar o Programa de Aceleração do Crescimento (PAC) do Governo Federal. O Programa possui como objetivo construir infraestrutura logística e energética para sustentar o crescimento do País. O objetivo de um Programa sempre terá a característica de ser abstrato, pois na concepção da idéia só há a expectativa do benefício e não do objeto entregável. Não sabemos exatamente o que terá que ser feito para que o benefício seja obtido, tampouco como.

O Governo Federal dividiu o PAC em seis Subprogramas e duas Frentes de Trabalho. Os Subprogramas do PAC são: PAC Energia, PAC Habitação, PAC Cidade Melhor, PAC Comunidade Cidadã, PAC Água e Luz Para Todos e PAC Transportes.

Cada um desses Subprogramas possui vários Projetos. Por exemplo, o Subprograma Cidade Melhor possui o Projeto Construção Estação de Tratamento de Esgoto na Baixada Santista, o Projeto de Construção de Drenagem Urbana na Baixada Fluminense, entre outros. E há também os Projetos internos do Programa que não são expostos à população, como Projetos de marketing para promover o Programa em rádio, TV e Internet, Projetos de Desenvolvimento de Sistemas de Informação do Governo etc.

Outra característica dos Programas é a existência das Frentes de Trabalho. Em tradução livre do The Standard for Program Management do PMI, Programas incluem elementos de trabalho não contidos em nenhum de seus Projetos. Esses elementos são as Frentes de Trabalho, que atravessam os Projetos, não necessariamente todos, apoiando a integração necessária para o benefício único do Programa. Como exemplo, a auditoria interna poderia ser uma Frente de Trabalho do PAC. As ações de auditoria atravessariam os Projetos gerando o benefício de integridade do Programa como um todo. Mas oficialmente o PAC possui duas Frentes de Trabalho: Medidas Institucionais e econômicas e a outra é Desenvolvimento Econômico Social.

A construção de uma usina hidrelétrica, por exemplo, se idealizada unitariamente, é um Projeto. Mesmo que leve 10 anos para ser construída e mobilize bilhões de reais, continuaria sendo um Projeto, e não um Programa, pois o que foi idealizado é o produto de forma direta.

Essa usina poderia estar dentro do Programa de Aceleração do Crescimento, e seria completamente normal caso a usina não tivesse sido idealizada no momento da concepção do Programa, pois se pensou no benefício da Aceleração do Crescimento no Brasil, e não em todas as entregas palpáveis que concretizariam esse benefício.

Programas geralmente possuem fases futuras totalmente abstratas em escopo, tempo e custo, muito mais abstratas que as fases futuras de um Projeto. De maneira rotineira, Programas são subdivididos em fases ou subprogramas. A primeira fase constantemente possui projetos visualizados com mais clareza ou já em execução. E a as demais com a visualização apenas da percepção do benefício desejado.

Após toda essa exposição conceitual, ainda perdura a dúvida: qual o problema em confundir Projeto com Programa ou vice e versa?

Conceber e executar um Projeto como Programa não é tão grave, mas certamente criará na corporação uma imagem errada do que é Programa e a sensação de que gerenciar Programa é o mesmo que gerenciar Projeto. E caso a corporação comece a implementar o conceito de Programa, terá dificuldade em difundir o conceito correto.

Porém, será catastrófico executar um Projeto quando na verdade for um Programa. O “Projeto” sofrerá aumento de escopo e prazo constantemente e a corporação não entenderá o motivo, mas ocorre que o peso de uma idéia estratégica, que é abstrata, foi delineado para ser entregue em um único “Projeto”, que possui um molde pontual e bem mais objetivo que a fase inicial de um Programa. O titulado “Projeto” nesse caso, terá inúmeras fases e mais cedo ou mais tarde essas serão tão independentes uma das outras que possuirão entregas totalmente diferentes, auto-suficientes e com objetivos próprios. Novos entregáveis começarão a ser criados no decorrer do ciclo de vida e não serão bem aceitos pela corporação, pois serão concebidos como se fossem incremento de escopo(scope creep) e causadores de atraso, quando na verdade são novos Projetos, independentes, e que apenas agora se visualizou a necessidade estratégica de criá-los e assim solidificar cada vez mais a expectativa abstrata inicial. Essa sucessão de desastres costuma ocorrer quando se faz a gestão de um Projeto sendo na verdade um Programa.

Artigos Relacionados:

1. Diferenciando Premissas de Restrições

A programação se dividiu basicamente em três partes. Tiveram sessões para Open Space (Discussão livre) de assuntos escolhidos pelos participantes no dia do evento; Sessões de workshop com temas emergentes na área de desenvolvimento de software; e Sessões chamadas de Lightening Talks (LT), onde cada palestrante tem 10 minutos para apresentar um tema. Os temas são propostos pelos próprios participantes do evento, e são apresentados de forma rápida e objetiva. O objetivo das LTs não é aprofundar a discussão sobre um determinado tema, mas apenas provocar os participantes e chamá-los para a discussão do tema, que pode ser útil nas sessões de Open Space.

Entrevistamos os organizadores do evento para falar um pouco sobre os objetivos e proposta do evento.

E-News PMI-SP: Como surgiu a ideia do evento?

Alguns organizadores do “Caipira Ágil” estavam participando do Encontro Agile Open 2010 e tiveram a ideia de realizar um evento com o mesmo foco aqui na região de Campinas, que apesar de ter um grande número de empresas de tecnologia, nunca teve um evento mais dinâmico e participativo como esse.

Nossa proposta foi fomentar a criação de uma comunidade em Campinas e região interessada em discutir melhores maneiras de desenvolver softwares utilizando as metodologias ágeis. Depois durante um Happy-Hour, outras pessoas se interessaram e formamos o grupo que iria organizar o evento (Alan Braz, Alberto Leal, Rafael Camargo, Renato Freire, Renne Rocha e Vitor Hugo).

E-News PMI-SP: Quais foram os objetivos do evento?

O objetivo primário era reunir durante um dia inteiro a comunidade ágil da região de Campinas. Queríamos criar um ambiente onde pessoas de diferentes níveis de conhecimento e formação pudessem discutir e aprender mais sobre a cultura ágil. Outro objetivo era que depois do evento, as pessoas continuassem a discussão por meio de redes sociais e encontros informais, estimulando as atividades da comunidade dessa região, criando e fomentando espaços para a troca de experiências, networking e desenvolvimento de projetos conjuntos.

E-News PMI-SP: Quais foram os perfis dos participantes e quantos se inscreveram?

Tivemos participantes com vários níveis de conhecimento e experiência profissional. Desde estudantes e curiosos que nunca trabalharam com metodologias ágeis, até profissionais que são referência na implantação, treinamento e utilização dessas metodologias no dia a dia. Foram cerca de 150 inscritos de 50 empresas e faculdades diferentes.

E-News PMI-SP: Como foram escolhidas as Lightening Talks (LT) e os assuntos dos Open Spaces (OS)?

As LTs foram propostas pelos próprios participantes, inscritos e selecionadas por meio de votação. Dessa maneira conseguimos fazer com que os temas escolhidos fossem reflexo do que os participantes realmente queriam conhecer e discutir. Como as LTs são curtas (10min), vários assuntos puderam ser abordados e posteriormente puderam ser discutidos nos Open-Spaces. Os Workshops foram escolhidos pela organização. Tentamos buscar profissionais com grande experiência e que pudessem dar uma visão mais prática dos conceitos e métodos de desenvolvimento ágil.

E-News PMI-SP: Como você avalia as contribuições do Open-Space?

O formato do Open-Space (http://en.wikipedia.org/wiki/Open_Space_Technology) não é muito conhecido aqui pois a maioria dos eventos tem o foco em palestras expositivas, onde os participantes são apenas ouvintes. No Open-Space tentamos incentivar a troca de experiências e o networking, como um dos objetivos principais, mas também fomentar discussões em que todos possam participar e contribuir com o conhecimento e experiências individuais. Apesar de não ter sido o espaço mais frequentado durante o “Caipira Ágil”, tivemos várias discussões muito interessantes (como um Dojo Kake e o Origami de Post-Its).

E-News PMI-SP: Qual a importância da metodologia ágil?

As metodologias ágeis são ferramentas adicionais que fazem parte da “caixa de ferramentas” e práticas dos profissionais. Apesar de já se terem passados mais de 10 anos do Manifesto Ágil (http://agilemanifesto.org/), pouco se discutiu sobre o real valor e utilização de Metodologias Ágeis. Por isso, destacamos o ponto de maior importância: compreender as metodologias e adicioná-las à sua “caixa de ferramentas”, ampliando o conhecimento para enfrentar os desafios do dia a dia dos projetos.

E-News PMI-SP: Pode-se esperar um novo evento como esse na região de Campinas?

Com certeza. Tivemos um retorno muito satisfatório e comentários positivos dos participantes e já estamos pensando em uma nova edição do “Caipira Ágil” no ano que vem. Além disso, temos outros projetos que ainda estão em fase de amadurecimento para continuar fomentando discussões dentro da comunidade durante todo o ano. Existe a ideia de um evento sobre startups ágeis, além do blog (blog.caipiraagil.com) que estamos pensando em como desenvolver o seu conteúdo. Dentre os temas abordados nas lightening talks durante o “Caipira Ágil”, tivemos:SCRUM “NA HORTA”: Usando metáforas, Matheus Haddad da Webgoal, apresentou alguns conceitos interessantes aplicados na prática. Uma empresa possuía uma pequena horta onde seus colaboradores plantavam e colhiam legumes e verduras. Foi então que os colaboradores tiveram a ideia de criar um projeto para dar manutenção na nossa horta utilizando o método Scrum, utilizada no desenvolvimento de seus projetos. Assim, eles puderam arrumar a horta e ao mesmo tempo proporcionar uma experiência real para os colaboradores da empresa que estavam passando pelo treinamento de Scrum. A apresentação de dez minutos da lightening talk contou com uma sessão de fotos, ilustrando como todo o processo ocorreu.

DESENVOLVIMENTO ÁGIL ORIENTADO À TESTES: UMA HISTÓRIA REAL DE COMO A BUSCA PELA QUALIDADE DE SOFTWARE TRANSFORMOU UMA EQUIPE DE DESENVOLVIMENTO JAVA

De acordo com Eder Ignatowicz da Dextra, garantir a qualidade tem sido um desafio constante nos projetos de software. Quer seja em desenvolvimento, integração, implementação ou customização de software, o aprimoramento da qualidade é considerada uma questão primordial por toda comunidade de desenvolvimento. A qualidade do produto desenvolvido é um dos principais fatores que influenciam no orgulho e na motivação de uma equipe de desenvolvedores.Na palestra apresentada durante o “Caipira Ágil” em 23/07/11, foi apresentado um case executado pela equipe Dextra em que foi demonstrado o resultado prático da busca pela maximização da qualidade de software através da aplicação de técnicas como TDD (JUnit), BDD (JBehave), ATDD (WebJBehave e Selenium), integração contínua (Jenkins) e inspeção contínua (Sonar) e principalmente, destacou a forma que estas técnicas e ferramentas influenciaram nos resultados da aplicação e transformaram o cotidiano de desenvolvimento da equipe gerando uma maior qualidade do produto desenvolvido.

O FUTURO DO AGILE

Vitor Hugo Germano abordou o tema de sua lightening talk focando em que o principal benefício da metodologia ágil não está em utilizar as ferramentas melhores, mas as mais eficientes e produtivas. O Desenvolvimento Ágil de software derrubou barreiras existentes na forma como interagimos dentro de um projeto: apresentando uma maneira direta de comunicação, através de equipes multidiciplinares e autogerenciaveis. Entregamos software mais rápido, fato.

Apesar do benefício, podemos dizer que ainda assim, entregar o software correto para nossos clientes está longe de se usar as melhores ferramentas, e invariavelmente não vai nos salvar de construir produtos inúteis. Outro fato: Projetos continuam falhando. Nosso ambiente organizacional ainda é repleto de descaso, falta de comprometimento, desconfiança, ameaças, e desinteresse por parte dos envolvidos. Surgem então, inúmeras dúvidas: Qual caminho seguir para se ter sucesso nos projetos? Como expandir nossa compreensão e nossas atitudes para tirar proveito dos benefícios similares de comprometimento e envolvimento que equipes ágeis parecem possuir?

Neste ambiente é que uma abordagem chamada Lean Startup tem ganhanhado força, principalmente nos ambientes de empreendedorismo tecnológico, forçando empresas a se tornarem ainda mais eficientes e objetivas. Valendo-se das práticas e valores Ágeis, o Lean Startup será mais uma das ferramentas que toda a empresa deverá conhecer para ter sucesso. A mudança real que está por vir vai muito além, e irá nos desafiar em valores fundamentais. Uma mudança distinta e dramática está tomando o lugar na filosofia por trás do comportamento organizacional, chamando à frente um novo conceito de humanidade. Este novo conceito é baseado numa compreensão expandida de nossas necessidades complexas e mutáveis, clamando por um mudanças em valores organizacionais, baseada em ideias democrático-humanitárias, que substituem o sistema mecanizado e despersonalizado da burocracia. Com isso, surge um novo conceito de poder, baseado na colaboração e razão, trocando o sistema baseado na desconfiança e controle.

Conseguimos expandir o conceito de autogerenciamento para esferas além de um projeto. Por exemplo o processo de contratação, que pode ser guiado pela necessidade definida pela própria equipe, que inclusive tem poder de veto na escolha de um candidato. Da mesma forma, ela participa ativamente na escolha de seus líderes, num ambiente transparente em que pode decidir como aplicar o orçamento da empresa juntamente com todos os demais funcionários.

GERENCIAMENTO ÁGIL DE PROJETOS – APLICAÇÃO EM PRODUTOS INOVADORES

Edivandro Conforto apresentou uma visão geral do livro “Gerenciamento Ágil de Projetos – aplicação em produtos inovadores”, recentemente lançado no Brasil. O objetivo foi mostrar o modelo de referência descrito no primeiro livro de Gerenciamento Ágil publicado no Brasil pela Editora Saraiva, dos autores Daniel C. Amaral, Edivandro C. Conforto, João L.G. Benassi e Camila de Araújo. O livro é resultado de pesquisas avançadas e pioneiras em gerenciamento de projetos e desenvolvimento de produtos inovadores, utilizando como foco a abordagem de gerenciamento ágil de projetos. Essas pesquisas foram reconhecidas por instituições internacionais da área de gerenciamento de projetos e gestão de operações.

A obra é pioneira no Brasil e inova no sentido de equilibrar práticas de gerenciamento de projetos tradicionalmente conhecidas e utilizadas pelas organizações com a abordagem ágil e conceitos consagrados de desenvolvimento de produtos. Apresenta um modelo de referência para aplicação da abordagem ágil em projetos de produtos inovadores, onde o ambiente de projetos é dinâmico e requer inovação, criatividade e entrega de valor para os clientes.

Colaborações:

Autor: Rafael Schincariol da Silva

Artigos Relacionados:

1. Na Busca por uma Definição para o Termo “Gerenciamento Ágil de Projetos”
2. Uma visão geral sobre a metodologia ágil Extreme Programming – XP
3. O CMMI e o gerenciamento da qualidade de projetos de software

Resumo

Palavras-chave:
Maturidade em Gerenciamento de Projetos; Modelos de Maturidade; OPM3; Porto Digital.

1. Introdução
O Porto Digital (2008) é definido como um Arranjo Produtivo Local (APL) de Tecnologia da Informação e Comunicação (TIC), com foco no desenvolvimento de software, que está situado no Recife, capital de Pernambuco, no nordeste brasileiro, é hoje, um dos principais pólos de tecnologia do país, resultado da implementação de políticas públicas em parceria com a iniciativa privada, universidades e órgãos de fomento do país. Alguns dados sobre o Porto Digital: 100 hectares; 120 organizações fazem parte; 4 mil empregos gerados; 2 incubadoras; 8 km de fibra ótica; representa 3,5% do PIB de PE.

Depois de ser apontado pela AT Kearney como o maior parque tecnológico do País em número de empresas e faturamento em 2005, o Porto Digital foi eleito durante o ano de 2007, como o Melhor Parque Tecnológico/Habitat de Inovação do Brasil pela a ANPROTEC. O reconhecimento veio através do Prêmio Nacional de Empreendedorismo Inovador 2007, considerado o principal desta área concedido no país.

Alguns estudos já foram realizados no Brasil com o objetivo de avaliar a maturidade das organizações, como o Estudo de Benchmarking em Gerenciamento de Projetos Brasil em 2006, 2007 e 2008 e os estudos publicados por Prado (2008). No entanto, fez-se necessária a realização de um estudo para avaliar o nível de maturidade das empresas do estado de Pernambuco. Baseada nisso, essa pesquisa procurou avaliar a maturidade de empresas vinculadas ao Porto Digital (BERBEL, 2008).

2. Modelos de Maturidade em Gerenciamento de Projetos
Um dos assuntos que vem ganhando cada vez mais espaço na área de gerenciamento de projetos atualmente, é a maturidade em gerenciamento de projetos. Segundo visões de diversos autores, maturidade é uma estrutura conceitual, composta por processos bem estabelecidos, através do qual uma organização desenvolve-se de modo sistêmico a fim de atingir um estado futuro desejado. A cada degrau alcançado nessa jornada, o modelo reconhece e sinaliza o amadurecimento progressivo da organização (PRADO, 2008; PMI, 2003; KERZNER, 2005).

O nível de maturidade de uma organização é uma maneira de prever seu futuro desempenho dentro de dada disciplina ou conjunto delas. A experiência mostra que as organizações funcionam melhor quando concentram seus esforços de melhoria de processos em um número controlado de áreas que exigem um esforço cada vez mais sofisticado à medida que a organização melhora. Um nível de maturidade é uma etapa evolucionária definida na melhoria de processos. Cada nível estabiliza uma parte importante dos processos da organização (SEI, 2006).

Para Pennypacker & Grant (2003) os modelos de maturidade prevê uma estrutura para avaliação que permite a uma organização comparar suas entregas de projetos com as melhores práticas ou contra seus concorrentes, enfim, definindo uma rota estruturada para o melhoramento.

Segundo Kerzner (2009) muitas vezes as empresas embarcam numa jornada com o objetivo de implantar o gerenciamento de projetos, e descobrem que o caminho que elas pensavam ser fácil na verdade é difícil e cheio de obstáculos. Sem compreender suficientemente os obstáculos e sem saber como ultrapassá-los, a organização corre o risco de jamais alcançar um alto nível de maturidade no gerenciamento de projetos. Ele ainda aponta sete erros/falácias mais comuns em gerenciamento de projetos que atrapalham a implantação/evolução da maturidade nas organizações: Objetivo errado; Critérios errados; Abordagem errada; Método errado; Maneira de incentivar errada; Apoio do executivo errado; Maneira de capacitar errada (KERZNER, 2009).

2.1. MMGP (Modelo de Maturidade em Gerenciamento de Projetos)
O MMGP, criado por Darci Prado em 2002, é um modelo de maturidade voltado tanto para setores dentro da organização como para o ambiente corporativo como um todo. O modelo é composto por cinco níveis: Inicial, Conhecido, Padronizado, Gerenciado e Otimizado.
Segundo Prado (2008) este modelo apresenta seis dimensões (ou aspectos fundamentais) da maturidade em cada um dos cinco níveis de maturidade em gerenciamento de projetos, a saber:

• 1) conhecimentos de gerenciamento;
• 2) uso prático de metodologias;
• 3) informatização;
• 4) relacionamentos humanos;
• 5) estrutura organizacional;
• 6) alinhamento com os negócios da organização.

A avaliação utilizando o modelo MMGP, como dito anteriormente, pode ser setorial ou corporativa. Ela é feita a partir da aplicação de um questionário contendo 40 perguntas. Com as respostas é possível calcular o nível de maturidade setorial ou corporativo da instituição.

2.2 PMMM (Kerzner Project Management Maturity Model)
O PMMM é um modelo de maturidade, desenvolvido por Kerzner (2005), que define o estágio atual, o planejamento, ações para implantação e desenvolvimento gradual da gerência de projetos. Este modelo busca a aplicação prática da gestão de mudança, na qual se tenta minimizar a resistência na implantação do sistema através da disseminação da cultura e orienta o seu planejamento.
O questionário do modelo PMMM contém 183 questões distribuídas da seguinte forma:

• Nível 1 (80 questões);
• Nível 2 (20 questões);
• Nível 3 (42 questões);
• Nível 4 (25 questões);
• Nível 5 (16 questões).

2.3 CMMI (Capability Maturity Model Integration)
O projeto CMMI envolveu uma grande quantidade de pessoas de diferentes organizações do mundo todo. Foi desenvolvido em 1986 pelo Software Engineering Institute (SEI) e busca a melhoria dos processos de desenvolvimento de software.

Um processo é um ponto de apoio da melhoria sustentada de uma organização. O objetivo do CMMI é fornecer direcionamentos para melhorar os processos de sua organização e sua capacidade de gerenciar o desenvolvimento, aquisição e manutenção de produtos e serviços. O CMMI aborda uma estrutura comprovada que ajuda a sua organização avaliar a sua maturidade organizacional ou a capacitação da área de processo, estabelecer prioridades de melhoria e implementá-las.

Nos modelos CMMI com representação em estágios, existem cinco níveis de maturidade, cada um representando uma camada da base da melhoria de processos, definidos pelos números de 1 a 5 (SEI, 2006).

2.4 OPM3 (Organizational Project Management Maturity Model)
A proposta do OPM3 é tornar-se um amplo modelo de maturidade que seja endossado e reconhecido mundialmente como um padrão para desenvolver e avaliar as capacidades de gerência de projetos em qualquer categoria de organização (PMI, 2003).

Esse modelo foi lançado no início de 2004 pelo PMI – Project Management Institute e contou com a participação de aproximadamente 800 voluntários de mais de 35 países, inclusive do Brasil, na sua elaboração.

O modelo inclui a recomendação de boas práticas, ou seja, as experiências vividas ao longo dos anos por diversas empresas e profissionais da área de gerência de projetos. Desse modo o modelo retrata uma trilha aparentemente segura e referenciada, capaz de orientar os gestores organizacionais nos seus investimentos e iniciativas de aprimoramento da operação de gerenciamento de projetos.
O OPM3 como outros modelos de maturidade organizacional procuram reconhecer e sinalizar as fases de amadurecimento progressivo da organização a cada degrau alcançado. Ao aplicar esse modelo a empresa obtém benefícios como:

• Habilitar a organização a promover os projetos certos, da maneira certa, alinhados estrategicamente em uma economia dinâmica e global;
• Permitir a flexibilidade de ser aplicado a diversos tipos de organizações, através de diferentes áreas de atuação, ramo de negócio, tamanho, localização geográfica, entre outros;
• Promover a conscientização e esclarecer a questão da maturidade organizacional por toda a alta direção;
• Associar diretamente o sucesso da organização à gestão eficaz e eficiente de projetos (REVISTA MUNDO PM, 2005).

O modelo OPM3 é formado por três domínios: Projeto, Programa e Portfólio; Quatro estágios de melhoria de processo (Padronização, Medição, Controle e Melhoria Contínua); e três elementos básicos que compõe o ciclo para implantação: Conhecimento, Avaliação e Melhoria. As capacidades estão mapeadas para cada um dos cinco grupos de processos em gerenciamento de projeto (iniciação, planejamento, execução, controle e encerramento). O desenvolvimento de capacidades em cada um dos grupos de processos descritos no PMBOK irá auxiliar a empresa na implantação dos planos de ações e contínua evolução de seus estágios de melhoria do processo. Cada domínio se comunica entre si por meio de ligações entre seus grupos de processos (PMI, 2004).

O OPM3 é o primeiro modelo que descreve as melhores práticas para gerenciamento de projeto, programa e portfólio em um modelo de maturidade. Além disso, é alinhado com um padrão aceito globalmente para a gerência de projeto, conhecido como PMBOK. O modelo evidencia a importância de utilizar um instrumento de avaliação, constituído por um questionário, através do qual o usuário analisa e responde sobre a presença ou não de processos formais associados ao ciclo de vida do gerenciamento de projetos (PMI, 2001).

A aplicação do modelo persegue o aprimoramento não apenas aos objetivos imediatos, mas sim procura o aprimoramento real dos processos organizacionais e da conquista de resultados mais adequados e previsíveis para os projetos da organização (SOLER, 2004).

3. Metodologia

Foram estudados modelos como MMGP (Prado) que é usado tanto para setores dentro da organização como para o ambiente corporativo (HARRISSON, 2006). O PMMM (Kerzner) é um modelo de maturidade que busca a aplicação prática da gestão de mudança, minimizando a resistência na implnatação do sistema através da disseminação da cultura e orienta o seu planejamento. O CMMI (SEI) fornece direcionamentos para melhorar os processos da organização e a sua capacidade de gerenciar o desenvolvimento, aquisição e manutenção de produtos e serviços. Para Zaguir e Martins (2007) o OPM3 (PMI) inclui a recomendação de boas práticas, abrangendo três elementos básicos (conhecimento, avaliação e melhoria), relacionados a dois fatores chaves: domínios de abrangência (projetos, programas e portfólio) e estágios de amadurecimento dos processos (estágio de padronização, de mensuração, de controle e de melhoria contínua).

Para elaboração do estudo foi escolhido o OPM3 pelo fato de muitas empresas já utilizarem outros modelos para avaliar a maturidade, e este modelo oferece o estágio de Melhoria Contínua que permite aumentar o nível de maturidade das empresas avaliadas (este elemento o diferencia bastante dos demais modelos existentes).

O processo de avaliação seguiu o do ciclo do OPM3 e foi realizado através de um software fechado que analisou os dados obtidos através dos questionários respondidos, além de verificar quais as melhores práticas que a empresa possui e calcular o nível de maturidade em GP.

Para realização do trabalho foi utilizada uma versão adaptada do questionário do OPM3 contendo apenas 70 perguntas referentes ao domínio de Projetos de um total de 151 perguntas do tipo Sim/Não. Não foi possível utilizar o software de avaliação oficial do modelo por conta dos custos.

Como o livro do modelo encontra-se na língua inglesa, o questionário foi traduzido para a Língua Portuguesa, disponibilizado na Internet e um link enviado através de convite eletrônico para 82 empresas do Porto Digital com um texto em anexo explicando a importância da pesquisa. Destas, apenas 5 responderam por completo o questionário e foram consideradas válidas para o aprofundamento do estudo.

As perguntas avaliam aspectos gerais sobre este domínio e também a aderência aos estágios de amadurecimento dos processos organizacionais: Padronização, Mensuração, Controle e Melhoria Contínua. Estas perguntas foram divididas em duas partes para que as empresas pudessem respondê-las com mais facilidade. O modelo se baseia num diretório que contém cerca de 600 melhores. Nesse trabalho foram observadas apenas as melhores práticas do domínio de projetos (ver Tabela 1.1).

Tabela 1.1. Divisão do Diretório de Melhores Práticas do OPM3, domínio de “Projetos”.

Como o software de avaliação que acompanha o modelo não foi utilizado para analisar as repostas do questionário, e, conseqüentemente, calcular o nível de maturidade, este cálculo foi realizado levando-se em consideração a existência dos processos relacionados ao domínio de projetos. Portanto o cálculo realizado foi: Maturidade = Nº de Processos Existentes / Processos Domínio de Projetos.

Com este cálculo foi possível encontrar o percentual de maturidade em relação ao Domínio de Projetos. O OPM3 também permite avaliar o percentual de maturidade em relação aos estágios de melhoria de processo: Padronização, Medição, Controle e Melhoria Contínua. Este cálculo também foi realizado levando-se em consideração o número de processos existentes em relação ao total de processos de cada estágio de melhoria. Ou seja, do total de 32 perguntas utilizadas para avaliar a maturidade, oito são para os processos de Padronização, oito para os processos de Medição, oito para os processos de Controle e oito para os processos de Melhoria Contínua.
Na última etapa do ciclo OPM3 existe a possibilidade de criar um plano de melhorias, porém sua realização não faz parte do objetivo deste trabalho. O objetivo inicial foi de descobrir o nível de maturidade das empresas do Porto Digital e não de propor melhorias para elas.

4. Descrição das Empresas Pesquisadas

4.1 Empresa “B”
A Empresa “B” do ramo de Tecnologia de Informação, sediada em Recife, é uma das empresas de desenvolvimentos em informática mais conhecidas do mercado nacional. Os primeiros projetos da empresa foram produzidos em março de 1991, mas ela só foi realmente firmada em outubro daquele ano. Depois disso, a Empresa “B” não parou mais de crescer somando inúmeros produtos e projetos bem sucedidos.

A Empresa “B” está presente em vinte e dois estados brasileiros. O acompanhamento de seus serviços é feito através de técnicos residentes que supervisionam os sistemas de cada cliente. São mais de 220 entidades que confiam seus sistemas a esta empresa. Com o intuito de levar solução para os seus clientes, a Empresa “B” desenvolve trabalhos nas seguintes áreas: consultoria e gestão; projeto e desenvolvimento de sistemas.

4.2 Empresa “C”
A Empresa “C” é um instituto privado de inovação que cria produtos, processos, serviços e empresas usando Tecnologia da Informação e Comunicação (TIC). Atuando há mais de 10 anos em âmbito nacional e internacional, a Empresa “C” interliga centros de inovação numa rede de conhecimento que realiza projetos de desenvolvimento conectados ao futuro, com qualidade e agilidade.

Em doze anos de trabalho foram gerados mais de 900 empregos diretos, além da participação na criação de mais de trinta empreendimentos e estabelecimento de parcerias com clientes em todo o Brasil e no mundo, levando a instituição de um faturamento de R$ 12 mil em 1996 a R$ 48 milhões em 2006, e tornando-a referência na área de TIC.

4.3 Empresa “J”
No mercado desde janeiro de 2000, a Empresa “J” com sede em Recife, é focada na criação de produtos inovadores com apelo ao público-alvo e sucesso comercial no mercado de jogos eletrônicos. Dedicada ao desenvolvimento das melhores soluções baseadas em jogos e prezando um ambiente de trabalho criativo, a empresa alia conhecimento técnico ao prazer de fazer o que gosta.

4.4 Empresa “P”
A Empresa “P” é uma empresa com larga experiência na área de Tecnologia da Informação (TI). Fundada em 1972, dedica-se ao desenvolvimento de sistemas de gestão em diversas áreas de atuação. Seus principais valores – Inovação, Evolução e Comprometimento – são fatores que projetam a empresa como uma das mais significativas fornecedoras de solução de gestão do país nos mercados privado e público.

Um dos maiores projetos da Empresa “P” é o Pirâmide, um ERP (Enterprise Resources Planning ou Solução de Gestão Empresarial), para o mercado privado, utilizado hoje por mais de 400 empresas e com mais de quatro mil usuários no Brasil. O Pirâmide atende a diversos segmentos de negócios, tais como sucroalcooleiro, saneamento, planos de saúde, hospitais, logística, indústrias, atacadistas, shopping centers, construtoras, empresas de serviços e organizações do terceiro setor.

A estrutura do produto conta com uma fábrica de software, uma operação comercial de marketing e vendas e um grupo de consultoria de negócios e implantação de sistemas. Esse ambiente tem certificação ISO 9001 e MPS.Br (nível G), e está em processo de certificação CMMI.

4.5 Empresa “W”
Fundada em julho de 2007, no Recife, a Empresa “W” é uma empresa de comunicação interativa focada em planejamento, desenvolvimento e gestão de projetos para a internet.

Os trabalhos da Empresa “W” caracterizam-se por focar nas necessidades do público-alvo de cada projeto. Dessa forma, desenvolvem soluções simples que resolvam as demandas do usuário final através de sites ou sistemas.

5. Análise da Maturidade em Gestão de Projetos das Empresas do Porto Digital
Após a aplicação do questionário junto às cinco organizações foi possível constatar as seguintes respostas:

A Empresa “W” obteve o menor nível de maturidade no domínio de Projetos entre as empresas pesquisadas (30%). Este baixo nível obtido pode ser justificado pelo fato desta empresa ter sido criada apenas no ano de 2007, não tendo tempo suficiente para implantar as melhores práticas sugeridas no OPM3.

A Empresa “B”, embora esteja no mercado desde o início da década de 90, não implantou grande parte das melhores práticas sugeridas pelo modelo. Sua avaliação foi de 40% no domínio de Projetos.

A Empresa “J” obteve 70% de nível de maturidade no domínio de Projetos, o que pode ser considerado um bom índice. Esta boa avaliação se deve ao fato da utilização de algumas metodologias de desenvolvimento de software como o Scrum e o XP (eXtreme Programming). A utilização destas metodologias demonstra a preocupação que a empresa possui em definir processos para aumentar a eficiência e competitividade da organização.

As Empresas “C” e “P” foram as que apresentaram os níveis mais elevados, 94,28% e 82,85%, respectivamente. A excelente avaliação obtida pela Empresa “P” pode ser explicada pelo fato dela já ter adotado outros modelos de maturidade como o CMMI e o MPS.Br. Já a Empresa “C”, por se tratar da referência de Tecnologia da Informação e Comunicação no país. Foi a que apresentou o melhor nível de maturidade entre as empresas pesquisadas. A tabela 1.2 a seguir, apresenta o nível de maturidade no domínio de “Projetos” das empresas pesquisadas.

Tabela 1.2. Nível de maturidade no domínio de “Projetos”.

6. Conclusão
O Porto Digital é um pólo de TIC fruto das parcerias públicas, privada, universidades e órgãos de fomento, tendo oito anos de existência e desenvolvendo soluções de TIC (Tecnologia da Informação e Comunicação). Tendo em vista que hoje é um parque tecnológico de grande destaque no Brasil e foi considerado como a melhor opção para se trabalhar.

A área de maturidade em gerenciamento de projetos ainda é um campo de estudo bastante vasto e pouco explorado principalmente por pesquisadores e empresas do Brasil, ainda mais as localizadas no Nordeste. Vários modelos existentes possuem suas peculiaridades e formas de implantação que vão de acordo com o tipo, tamanho, faturamento, entre outras características que devem ser levadas em conta no momento da escolha/seleção de um modelo. Os modelos procuram unificar uma mesma visão tratando a evolução da maturidade como estágios de crescimento no qual as organizações vão evoluindo e conquistando um maior grau de maturidade em relação ao gerenciamento de projetos.

As organizações modernas sendo de pequeno, médio ou grande porte devem utilizar os conceitos e modelos de maturidade para acelerar o crescimento, no que diz respeito a práticas, processos, definição de responsabilidades e nível de maturidade. Maturidade é um objetivo móvel, visto que seus principais elementos (tecnologia, metodologia e gestão) mudam continuamente em função do mercado, dos negócios e das pessoas (RABECHINI JÚNIOR, 2003).

Nesse estudo foram avaliadas 5 empresas quanto ao nível de maturidade em gerenciamento de projetos segundo o modelo OPM3: Empresa “W” (planejamento, desenvolvimento e gestão de projetos para WEB) com 30%; Empresa “B” (soluções na área de consultoria, gestão e desenvolvimento de TI) com 40%; Empresa “J” (criação de jogos eletrônicos) com 70%; Empresa “P” (desenvolvimento de sistemas de gestão) com 82,85%; e Empresa “C” (criação de produtos, serviços e empresas de base tecnológica) com 94,28%.

Os produtos finais oferecidos por empresas de tecnologia normalmente são diferenciados, únicos, voltados para clientes individuais, sendo necessários projetos distintos para elaboração de cada produto final.

O OPM3 serve como um guia bem estruturado e detalhado para aplicação das melhores práticas de gerenciamento de projetos com vistas a alcançar os objetivos estratégicos da organização através da realização de projetos de sucesso. Desenhado para ser fácil de entender e ser usado por qualquer um que tenha interesse em maturidade e desenhado para ser escalável e flexível: atender a organizações de diferentes tipos e tamanhos.

As organizações devem desenvolver e manter a competência adequada com mais eficiência e eficácia (capability); o exercício contínuo de melhoria faz com que a organização atinja o mais alto patamar de maturidade (maturity), de acordo com suas possibilidades (forças e fraquezas) e objetivos empresariais (CHRISSIS et al., 2003).

Referências Bibliográficas

BERBEL, A. C. A. O processo de internacionalização de um cluster de empresas de software: o caso do Porto Digital. 2008. 101 f. Dissertação (Mestrado em Administração).

CHRISSIS, M. B.; KONRAD, M.; SHRUM, S. CMMI: guide for process integration and product improvement. Boston: Addison-Wesley, 2003.

HARRISSON, P. D. Análise e resultados da aplicação de modelos de maturidade em gerenciamento de projetos em uma organização: um estudo de caso. 2006. 206 f. Dissertação (Mestrado em Engenharia Naval). Escola Politécnica – Universidade de São Paulo, São Paulo, 2006. Disponível em:
http://www.teses.usp.br/teses/disponiveis/3/3135/tde-23072007-225730 Acesso em 12 de nov. 2008.

KERZNER, H. Sete Falácias que Atrasam a Maturidade do Gerenciamento de Projetos. Revista Mundo PM, v. 5, n. 28, p. 08-11, 2009. ISSN: 1807-8095.

KERZNER, H. Using the Project Management Maturity Model: Strategic Planning for Project Management. 2. ed. EUA: Wiley, 2005.

PENNYPACKER, James S.; GRANT, Kevin P. Project Management Maturity: An Industry Benchmark. Project Management Journal. Vol. 34, p. 4-11, Mar. 2003.

PMI – Project Management Institute. Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos (PMBOK). 3. ed. Newton Square: Project Management Institute, 2004.

PMI – Project Management Institute. Organization Project Management Maturity Model (OPM3). Newton Square: Project Management Institute, 2003.

PMI – Project Management Institute. Organizational project management maturity model (OPM3). 2001. Disponível em: http://www.pmi.org/opm3. Acesso em 07 Outubro de 2006.

PORTO DIGITAL. Disponível em: http://www.portodigital.org. Acesso em 15 de out. 2008.

PRADO, D. S. Maturidade em Gerenciamento de Projetos. Nova Lima: INDG Tecnologia e Serviços Ltda., 2008.

RABECHINI JÚNIOR, R. Competências e Maturidade em Gestão de Projetos: uma perspectiva estruturada. 2003. 252 f. Tese (Doutorado em Engenharia de Produção) – Escola Politécnica (USP), São Paulo, 2003.

REVISTA MUNDO PM. Bimestral. Curitiba: Mundo, 2005. ISSN 1807-8095.

SEI – Software Engineering Institute. CMMI for Development: Improving processes for better products. CMMI-DEV 1.2. Pittsburgh, PA: Carnegie Mellon University, 2006.

SOLER, A. M. Maturidade Organizacional e o Modelo de Avaliação PMI-OPM3. 2004.

ZAGUIR, N. A; MARTINS, M. R. Revisão crítica do OPM3: um estudo de redundâncias. Gestão Industrial, Paraná, v. 3, n. 1. 2007. p. 75-86. Disponível em: http://www.pg.cefetpr.br/ppgep/revista/revista2007/vol1/artigo/V3N1B7.pdf Acesso em 03 dez. 2008.

Autores: José Gilson de Almeida Teixeira Filho, Diego Santiago Figueirôa, Hermano Perrelli de Moura, Talita Ferreira de Souza e Laís Carla Venâncio Rodrigues

Artigos Relacionados:

1. Escritórios de projetos: tendências e níveis de maturidade
2. Gerenciamento de Projetos em Empresas Orientadas para Projetos – Estudo de Caso na França (Alstom Transport)
3. A Influência da Maturidade das Partes Interessadas em Gerenciamento de Projetos na Engenharia e Construção

1. Introdução
Na escassa literatura sobre Comissionamento de Sistemas e Subsistemas em projeto industriais, a definição do termo é inebriada pela grande amplitude pelo qual o seu escopo pode ser interpretado e pelas diversas formas de inseri-la no contexto de gerenciamento de projetos, ou seja, há pouca clareza e até mesmo divergências, sobre a definição do conceito de Comissionamento: é uma fase do projeto, uma área de conhecimento, um processo de gerenciamento de projetos a “la PMBoK”, um subprojeto, ou uma atividade? Corroborando as dúvidas citadas acima, o International Electrotechnical Commission (2006: 5) afirma que: “There is an increasing trend in the process industry to award the construction of whole plants to contractors on a lump-sum turnkey or similar commercial basis. Experience has shown that both the process industry (hereinafter called “the owner”) and the contractor have long and expensive discussions to lay down unambiguously the scope of activities to be taken by the contractor and the owner and their responsibilities to achieve the handover of the plant”.

A fim de sugerir uma definição mais clara e estabelecer limites para entendimento de seus limites, este trabalho parte da ótica de um gerente de projetos que tem por objetivo planejar, executar e entregar um empreendimento para um cliente final.

Além de sugerir uma definição mais clara para o conceito de Comissionamento, o trabalho se contextualiza no âmbito do gerenciamento de projetos entendido pelo Project Management Institute (PMI) no PMBoK e no Construction Extension to The PMBoK. Com base na experiência profissional e teórica dos autores, o conjunto de conhecimentos compilados nestas duas publicações do PMI, não é suficiente para executar o Controle da Qualidade em projetos industriais, pois limita-se em considerar como ferramentas e técnicas: Inspeção e Revisão de Reparo de Defeito. Lembrando que o processo de Verificação do Escopo (quando ocorre a aceitação das entregas pelo cliente) não faz parte do Comissionamento, como será visto adiante.

A partir da proposta de definição e de limites do escopo do Comissionamento, os autores sugerem ainda a identificação e divisão de mais três atividades, antes entendidas (de forma não consensual) como subatividades internas do Comissionamento, quais sejam: Condicionamento, Partida e Operação Assistida.

A consideração do Comissionamento, condicionamento, partida e operação assistida como atividades independentes, facilita o entendimento dos limites de cada atividade que, no entender dos autores, requerem um conjunto de técnicas e ferramentas distintas a fim de serem executadas.

Por fim, este trabalho está em plena sintonia ao conjunto de conhecimentos do PMI, apenas complementando o processo de realizar o Controle da Qualidade, quando se tratada do gerenciamento de projetos industriais. O benefício desta iniciativa é tornar mais transparente a ligação entre o processo de Controle da Qualidade e o processo de Verificação do Escopo (quando ocorre a aceitação das entregas pelo cliente).

Este artigo refere-se à visão restrita dos autores, tratando-se de uma crítica construtiva para o avanço do conhecimento (que não se esgota neste trabalho), não tendo a intenção de desqualificar visões alternativas. Além disso, este artigo incorpora a experiência profissional do autor quando esteve em contato com algumas outras boas práticas utilizadas por empresas do setor de exploração e produção de óleo e gás, da indústria naval e de construção e montagem (Empreiteiras) complementando as versões anteriores deste artigo publicadas por Gandra e Lopes (2009) e Gandra (2010).

2. Comissionamento e a diversidade conceitual na literatura
Qual o significado, qual o escopo, e onde se insere o conceito de Comissionamento na literatura de gerenciamento de projetos atualmente? Ele é uma fase do ciclo de vida do projeto, um processo de gerenciamento de projetos a “la PMBoK”, um subprojeto, ou um conjunto de atividades (técnicas e ferramentas)? Nesta sessão, será feita uma breve consulta à literatura disponível para que se possa observar a amplitude conceitual sobre o tema.

Segundo a ScottMadden (2009), o Comissionamento é entendido como uma fase do ciclo de vida do projeto, onde ocorre: a certificação, os testes de operabilidade dos equipamentos, a partida, a certificação da estabilidade da eficiência operacional, e a manutenção das entregas dos documentos de projeto. Embora não haja certo e errado para esta questão, esta visão parece ser pouco objetiva, pois o Comissionamento aparece como uma fase anterior à fase de encerramento do projeto (Figura 1). Além disso, a experiência tem mostrado que o Comissionamento pode estar presente em todas as fases do ciclo de vida do projeto e o quanto antes for feito, maior qualidade será alcançada nas entregas e mais ágil a obtenção da aceitação do cliente (no processo de Verificação de Escopo).

De Souza (2002: 47) também define o Comissionamento como fase do ciclo de vida do projeto, permitindo “garantir que o projeto esteja de acordo com as necessidades do usuário. É a validação do projeto pelo cliente. A aprovação final do cliente ocorre durante a posta em marcha, quando o sistema é colocado em funcionamento. (…) A validação objetiva é a garantia de que o projeto está de acordo com as necessidades do usuário, conforme condições operacionais. Desta maneira, fica registrado que o projeto atingiu seus objetivos junto ao cliente”. Ele ainda acrescenta a possibilidade de haver a exigência, por parte do cliente, de uma etapa adicional denominada “operação assistida”, onde a estabilidade operacional da planta é atingida. Desta forma, a partida da planta (startup) e a garantia de sua estabilidade operacional fariam parte desta fase denominada por Comissionamento. Esta visão do Comissionamento como fase do ciclo de vida do projeto sugere que ele ocorra apenas no final do projeto. Além disso, De Souza (2002) parece inserir o Processo de Verificação do Escopo dentro do Comissionamento. Contrapondo esta visão, ao que parece, fica mais claro sugerir que o Comissionamento é um conjunto de ferramentas que servirá de insumo para o Processo de Verificação do Escopo e obtenção da aceitação final do projeto pelo cliente.

Figura 1. Entendendo Comissionamento como Fase de Projeto segundo ScottMadden (2009). Apresentação retirada em 03/06/2006 do site da internet: http://scottmadden.com/insight/267/Project-Controls.html)

Como o Comissionamento foi tradicionalmente concebido como um conjunto de atividades executadas nas fases finais de construção e montagem, ele acaba sendo considerado como uma fase do ciclo de vida do projeto (embora atualmente se reconheça que ele não ocorre apenas nas fases finais do projeto). Contudo, a experiência tem mostrado que o sucesso dos projetos tem correlação positiva com a antecipação das atividades preventivas (tal como ocorre com o Comissionamento), uma vez que os custos de prevenção são menores que os custos de correção. Desta forma, é natural supor que o Comissionamento venha ocorrer desde as fases iniciais do ciclo de vida dos projetos até o final.

Concebendo o Comissionamento como uma fase do ciclo de vida do projeto, onde ocorrem diversas atividades simultâneas, denominadas pela mesma palavra, além de gerar confusão conceitual (como se tem observado em diversos anexos de contratos de EPC para implantação de unidades industriais) contribui, ainda, para gerar impasses de natureza contratual entre contratada e cliente. A falta de objetividade de sua definição e amplitude de seu escopo pode gerar frustrações no que diz respeito à dificuldade apontamento das atribuições e das responsabilidades, ou seja, a ideia é “quebrar” o conceito de Comissionamento e dividi-lo em outros, a fim de delimitar seu escopo.

Do ponto de vista de quem é o executante do projeto, o Comissionamento pode ser um subprojeto ou um projeto a parte; mas isto ocorre apenas na visão de quem foi contratado para planejar, executar e finalizar o serviço de Comissionamento. Para o Gerente do Projeto que tem a responsabilidade de planejar, implantar e entregar o produto final com qualidade requerida em contrato, o Comissionamento será apenas um conjunto de ferramentas e técnicas utilizadas para o processo de realização do Controle da Qualidade (inserido na área de conhecimento de Gerenciamento da Qualidade do PMBoK). Uma vez atestada à qualidade requerida, o projeto passa pelo Processo de Verificação do Escopo, onde ocorre a aceitação das entregas pelo cliente até a assinatura do Termo de Aceitação (quando será iniciada as atividades de encerramento do projeto). Deve-se ter em mente que pode haver a Verificação do Escopo de partes do projeto ao longo do ciclo de vida, mas a Verificação Final do Escopo (VFE) do projeto como um todo só ocorre com a assinatura do Termo de Aceitação.

Esta visão parece ser corroborada por Gaete e Prates (2007) que definem o Comissionamento como: “conjunto de técnicas e procedimentos de engenharia aplicados de forma integrada a uma unidade (ou planta) industrial, visando torná-la operacional, dentro dos requisitos estabelecidos pelo cliente final. Assegurar a transferência da unidade industrial do construtor para o operador de forma ordenada e segura, garantindo sua operabilidade em termos de desempenho, confiabilidade e rastreabilidade de informações”.

A Figura 2 ilustra o escopo das atividades de Comissionamento na visão de Gaete e Prates (2007), que embora apresente um escopo amplo, é mais clara e definida que as visões apresentadas anteriormente. Note que o Pré-comissionamento, a Preparação de Partida, a Partida, e a Operação Assistida fazem parte de uma pseudo-atividade denominada por “Grade Comissionamento”. Para efeito de um melhor esclarecimento dos limites das subatividades do “Grade Comissionamento”, nas sessões seguintes, estas atividades serão, como proposta deste trabalho, decompostas em atividades independentes e receberão outras denominações.

Figura 2. Exemplo Metodológico para Aplicação do Comissionamento Durante o Ciclo de Vida do Projeto segundo Gaete e Prates (2007)

3. Gerenciamento da Qualidade Segundo PMBoK

O PMBoK divide o Gerenciamento de Projetos em uma matriz de nove áreas de conhecimento (Integração, Escopo, Tempo, Recursos Humanos, Qualidade, Risco, Custos, Aquisições, e Comunicação), por cinco Grupos de Processos de Gerenciamento de Projetos (Iniciação, Planejamento, Execução, Monitoramento e Controle, e Encerramento). Dentro de cada intersecção de linhas e colunas, podem ser encontrados diversos processos de gerenciamento de projetos.Segundo o Capítulo 8 do PMBoK e do Construction Extension to The PMBoK, os processos de gerenciamento da qualidade do projeto incluem todas as atividades da organização executora que determinam as responsabilidades, os objetivos e as políticas de qualidade, de modo que o projeto atenda às necessidades (e aos requisitos) que motivaram sua realização. Para tanto, são identificados 3 processos de gerenciamento da qualidade do projeto, descritos abaixo.

• Planejamento da Qualidade: identifica e documenta formalmente os padrões de qualidade incluindo métricas, normas, metas e limites de tolerância relevantes ao projeto, e determina os procedimentos que deverão ser atendidos para satisfazê-los, assim como os responsáveis. Além disso, define a linha de base de qualidade (requisitos de sucesso do projeto em termos de gerenciamento e de entregas).
• Garantia da Qualidade: identifica as sistemáticas e procedimentos para garantir que o projeto execute todos os processos necessários de gerenciamento de projetos em conformidade aos requisitos definidos contratualmente. Este processo visa à otimização e a melhoria contínua dos processos de gerenciamento de projetos para reduzir os desperdícios e eliminar as atividades que não agregam valor. Importante destacar que este processo é voltado para a melhoria da qualidade dos processos e procedimentos de gerenciamento de projetos em si, e não das entregas (produtos ou serviços) encomendadas. As principais ferramentas deste processo são: Análise de Processos e Auditorias de Qualidade.
• Controle da Qualidade: monitora os resultados das entregas (produtos e serviços) específicos ao projeto, a fim de determinar se elas estão de acordo com os padrões e normas de qualidade requeridas contratualmente, e identifica maneiras de eliminar as causas do desempenho insatisfatório. Os padrões de qualidade incluem metas de produtos e também dos processos necessários para sua confecção. As ferramentas destacadas no PMBoK são: Diagrama de Causa e Efeito (Ishikawa / Espinha de Peixe), Gráficos de Controle, Fluxogramas, Histograma, Diagrama de Pareto (80/20), Amostragem Estatística, Diagrama de Dispersão, Inspeção (para garantia de atendimento às normas de projeto), e Revisão de Reparo de Defeito (caso haja uma não conformidade no equipamento na Inspeção). Este processo é direcionado à qualidade das entregas (produtos ou serviços) encomendadas (em atendimento ao que foi definido em contrato). Podemos destacar as seguintes ferramentas: Inspeção e Revisão de Reparo de Defeito. Uma inspeção é o exame de um produto do trabalho para determinar se ele está de acordo com as normas. As inspeções podem ser conduzidas em qualquer nível. Por exemplo, é possível inspecionar os resultados de uma única atividade ou o produto final do projeto. As inspeções também são chamadas de revisões, avaliações por pares e geralmente ocorrem in loco (ou seja, dentro do fornecedor). As inspeções servem para validar a Revisão de Reparo de Defeito (caso haja uma não conformidade). Contudo, o PMBoK limita-se a explicar Inspeção e Revisão de Reparo de Defeito, quando em projetos industriais, estas ferramentas não são suficientes e, portanto, deve ser complementado.

Com o objetivo de complementar o PMBoK, uma vez que as entregas (fornecimento de equipamentos e módulos) sejam aceitas, estes suprimentos podem ir para estoque do projeto (para o canteiro de obras), onde deverão ser aplicadas técnicas de condicionamento (ou preservação) até sua aplicação. Note que esta é a visão de um integrador (i.g.: “EPCista”), onde ele recebe os suprimentos, coloca em estoque (no canteiro) e mantêm este equipamento preservado até a hora de sua montagem no projeto. Após isto, uma vez iniciada a fase de Construção & Montagem destes equipamentos, conforme Gaete e Prates (2007): executar-se-ão procedimentos e técnicas de engenharia, de forma integrada, a fim de tornar operacional a unidade (ou planta) industrial, dentro dos requisitos estabelecidos pelo cliente final. É neste contexto que o Comissionamento e outras técnicas serão aplicados. Além disso, deve-se considerar que estas técnicas se aplicam à todas as disciplinas de engenharia: construção civil, caldeiraria, tubulação, máquinas, elétrica, instrumentação e automação, eletrônica, e processo.

4. Condicionamento, Comissionamento, Partida e Operação Assistida como Ferramentas do Processo de Controle de Qualidade em Projetos Industriais

No processo de realizar o Controle da Qualidade, muito embora a ferramenta de Inspeção sirva para homologar as entregas ou encaminhar à revisão de Reparo de Defeito (caso haja uma não conformidade), o PMBoK e o Construction Extension to The PMBoK não explicitam a necessidade de preservação uma vez que os equipamentos foram aceitos e supridos pelos fornecedores, assim como não detalham a necessidade de testes que assegurem a operabilidade do sistema como um todo. Desta forma, a fim de complementar o PMBoK, deve-se destacar a importância da inclusão das seguintes ferramentas (técnicas ou atividades) descritas abaixo e largamente utilizadas em processos industriais.

• Condicionamento ou Preservação => É o processo que tem por objetivo assegurar preventivamente que os componentes de uma edificação ou uma unidade industrial (assim como o sistema) sejam rotineiramente inspecionados, a fim de ter a integridade mantida. Consiste na aplicação integrada de um conjunto de técnicas e procedimentos de engenharia para preservar cada componente físico do empreendimento, desde os equipamentos individuais (como peças, instrumentos e equipamentos), até módulos, subsistemas integrantes de um projeto. Esta atividade ocorre uma vez que os equipamentos e componentes tenham passados pela atividade de Inspeção (atentando, assim, a sua conformidade) e tendo sido aceito para entrega no estoque do canteiro de obras até sua aplicação pela firma integradora do projeto (i.g.: “EPCista”). Geralmente são conhecidos por: testes sem carga (“testes a frio”). É necessário um plano e um sistema gerencial de programação da rotina de preservação para cada equipamento (descrevendo, inclusive, os procedimentos recomendados pelo fabricante e os recursos necessários). Principais exemplos de atividades de Condicionamento são: limpeza, secagem, pintura, lavagem, calibração de válvulas, aplicação de regras de estocagem, energização de equipamentos, flushing de sistemas de lubrificação, inertização de equipamentos (por exemplo: através de injeção de hidrogênio para retirada de oxigênio e, portanto, de umidade a fim de evitar oxidação ou explosão).
• Comissionamento ou Pré-Operação => É o processo que tem por objetivo assegurar preventivamente que os componentes, equipamentos, módulos, e sistemas de uma edificação ou unidade industrial, assim como a integração e completação entre eles, sejam testados para que os requisitos de operação estejam de acordo com o que foi contratado pelo cliente. O Comissionamento consiste na aplicação integrada de um conjunto de técnicas e procedimentos de engenharia para verificar e testar cada componente físico do empreendimento, desde os equipamentos individuais como peças, instrumentos e equipamentos, até os módulos, subsistemas e sistemas completos. Geralmente são conhecidos por: testes com carga (“testes a quente”). Também faz parte do Comissionamento sua subdivisão, como foi optada neste artigo as subatividades conhecidas por: Pré-comissionamento, Pré-operação e Preparação de Partida. Principais exemplos de atividades de Comissionamento são: testes de malhas elétricas “loop test”, testes hidrostáticos, testes de instrumentação, e testes de completação mecânica dos sistemas e subsistemas, e identificar deficiências para solicitação de reparos de defeitos para realização de correções.
• Partida (Startup) => Não se deve entender “partida” como um marco, pois é uma atividade que pode ser executada em um período de tempo onde serão aplicados diversos procedimentos recomendados pelo fabricante das unidades, além da execução da sequencia de partida, tal como planejado. Além disso, para encerramento desta atividade não é necessário que o projeto esteja operando em sua plena capacidade ou normalidade, pois a estabilização da operação será executada na atividade de Operação Assistida. Segundo (Parodi, 2001) “Startup ends only when the project is in routine operation although not necessarily at full design capacity production”.
• Operação Assistida ou Estabilização da Operação => Esta atividade ocorre após a partida, cujo objetivo é a estabilização da operação das unidades ou do sistema, atestando a confiabilidade da eficiência definida previamente acordada entre as partes. Após a Operação Assistida, finaliza-se o Processo de Verificação de Escopo, onde se espera que, de fato, todo o sistema seja aceito pelo cliente. Esta é a fase na qual se dá a transferência dos sistemas à operação.

Já a Entrega pode ser entendida como uma “Fase de Transição” entre a Construção & Montagem e Operação. Muito embora o Processo de Verificação do Escopo aconteça durante todo o ciclo de vida do projeto, é na fase da Entrega que ocorre a Verificação Final do Escopo (VFE) onde ocorre a aceitação, pelo cliente, do projeto como um todo. Lembrando que a Verificação do Escopo faz parte do grupo de processos de monitoramento e controle. O Comissionamento, Condicionamento, Partida e Operação Assistida não fazem parte do Processo de Verificação de Escopo, mas sim do Processo de Controle da Qualidade, e serão utilizados no primeiro processo para aceitação das entregas. Na fase de Entrega, mediante assinatura do Termo de Aceitação do projeto como um todo, pode-se passar para os processos de Encerramento do Projeto (onde ocorre a entrega de: arquivos de projetos, data book, as-built, plantas, desenhos, os registros de lições aprendidas, etc) e de Encerramento Contratual.

Lembrando que, no Planejamento do Projeto, são gerados todos os planos e documentos de planejamento, incluindo: Plano de Gerenciamento do Condicionamento, Plano de Gerenciamento do Comissionamento, Plano de Partida e Plano de Operação Assistida. É recomendável que cada um possa, quando aplicável, contemplar o planejamento em termos de: responsabilidades, estrutura analítica (EA), cronograma com rede de precedência e recursos (Resource Loaded Schedule), estimativa de custo, normas, metas, procedimentos, técnicas, ferramentas, rotinas, softwares que são aplicados em cada atividade, documentos que serão gerados, testes de aceitação de desempenho, plano de comunicação, e, quando aplicável em contrato, os manuais de operação.

Importante salientar que, na entrega, não só o Plano de Gerenciamento da Qualidade (contendo os Planos de Condicionamento, Comissionamento, Partida, Operação Assistida), como também o Relatório Final de Comissionamento deverão ser entregues ao cliente final. Este relatório, a exemplo do Relatório de Estudo de Comissionamento (RECOM), deve ser entregue ao Operador do Sistema Elétrico (ONS) e no caso da implantação de um projeto no sistema elétrico brasileiro, deve-se conter: informações sobre os teste e ensaios realizados com descrição detalhada, condições de realização, métodos, normas, recomendações do fabricante; pendências de Comissionamento com reflexo operativo; limitações operativas resultantes das pendências de Comissionamento e plano de ação para eliminação de pendências e limitações operativas. O desempenho do Comissionamento também deve ser medido e monitorado, quando esta atividade for contratada pelo projeto como um serviço à parte.

Para um melhor entendimento, a Figura 3 ilustra a sequencia das atividades para realização do Processo de Controle da Qualidade das entregas do projeto e suas fases do ciclo de vida. Durante o suprimento (que é uma atividade do Gerenciamento de Aquisições), acontece a atividade de Inspeção e Reparo de Defeitos. O Condicionamento ocorre à medida que os equipamentos são entregues à empresa integradora e são estocados até a sua aplicação no projeto. Segundo International Electrotechnical Commission (2006: 6): “Construction and precommissioning activities could be overlapping”.

Após o sistema comissionado (ou seja, “testado a quente”), inicia-se a atividade de Partida e, posteriormente, de Operação Assistida (necessária para estabilizar a eficiência operacional do sistema como um todo).

Para que se possa avaliar, aferir e atestar a conformidade física do item condicionável em relação às especificações técnicas de projeto, operabilidade, conformidade física, e requisitos da qualidade, de segurança, de meio ambiente e saúde (QSMS), é normal que se faça um gerenciamento por pendências. Qualquer desvio que afete esses requisitos pode ser visto como pendência a ser resolvida. Assim, podem-se classificar as pendências por nível de gravidade, tal como exemplo abaixo.

• Pendências Tipo “A” (relevantes): representam aquelas que impedem a continuidade das atividades na fase seguinte, principalmente nos itens relacionados com segurança, integridade e desempenho dos equipamentos/sistemas, e que deverão ser completamente eliminados da fase na qual foram identificados.
• Pendências Tipo “B” (não relevantes): representam aquelas que não impedem a continuidade das atividades na fase seguinte, principalmente nos itens relacionados com segurança, integridade e desempenho dos equipamentos/sistemas, mas deverão ser reparadas o mais rápido possível antes da fase de Partida/Operação.
• A depender da gravidade das pendências identificadas, pode-se formular emissão de níveis de aceitação dos itens, malhas, subsistemas, também exemplificados abaixo.
• Termos de Transferência e Aceitação do Sistema (TTAS), que pode ser subdividido em:

1. TTAS-1, quando o sistema envolvido apresenta somente itens pendentes do Tipo “B”;
2. TTAS-2, quando o sistema envolvido não apresenta itens pendentes do Tipo “A” e do Tipo “B”.

• Termo de Recebimento Provisório da Unidade (TRPU), que pode ser emitido com algumas Pendências Tipo “B” (não relevantes) abertas. O ideal é que a partida das unidades industriais aconteça somente quando todos os itens pendentes de comissionamento tiverem sido eliminados, ou seja, quando houver a emissão de 100% das TTAS-2. Contudo, isto não ocorre, pois não é conveniente do ponto de vista econômico, pois pode atrasar a partida e, por consequência, a geração de receita para a empresa / cliente. Assim, opta-se partir a unidade industrial mesmo com, pendências Tipo “B” (não relevantes) abertas (isto é, mesmo com carryover). A Operação Assistida sim deve iniciar quando houver a emissão de todas as TTAS-2.
• Termo de Recebimento Definitivo (TRD) ou Verificação Final do Escopo (VFE) ocorre quando há a conclusão satisfatória da Operação Assistida, com a unidade industrial atendendo todos os requisitos pré-estabelecidos, sem pendências e aprovação de toda documentação final referente ao escopo deste serviço, devidamente atualizada, contendo todas as evidências. É neste momento que o Termo de Aceitação do Projeto como um todo, é assinado pelo cliente – a partir daí pode-se iniciar as atividades de Encerramento do Projeto e Encerramento Contratual. Após a emissão do Termo de Recebimento Definitivo (TRD), entrega-se o ativo para operação do cliente. Importante ressaltar que, muito embora o processo de Verificação do Escopo aconteça durante todo o ciclo de vida do projeto, é na fase da Entrega que ocorre a Verificação Final do Escopo (VFE) ou emissão do Termo de Recebimento Definitivo (TRD).

Para gestão do comissionamento, é necessário utilizar um software específico, onde todas as pendências impeditivas ou não impeditivas devem ser registradas. Abaixo segue os exemplos mais usuais de pacotes comerciais disponíveis no mercado:

• CMSapp Database, desenvolvido por CMScompletion (Singapura)
• GO-CMMS, desenvolvido por QED International (UK)
• Go-Console, desenvolvido por Lucy Software BV (Holanda)
• HMSWeb©, Handover Management System, desenvolvido por HMSWeb Ltda / Forship Engenharia (Brasil)
• PCMsys, desenvolvido por PCM Engenharia (Brasil)
• PIMS CMS, desenvolvido por Omega (Noruega)
• PWCom, desenvolvido por Portreef (Austrália)
• WinPCS, desenvolvido por Complan (Noruega)
• PRECOM, desenvolvido pela Techint (Argentina)

Além disso, é comum observar os itens comissionáveis abrangendo os equipamentos identificados por um código individual (TAG Number). Contudo, o universo de itens comissionáveis devem ser avaliados para não gerar trabalho desnecessário ou para que não haja um “sobre-esforço” na atividade de gerenciamento do comissionamento.

5. Considerações Finais

A falta de objetividade de definição do termo, Comissionamento, e seu entendimento como uma fase do ciclo de vida do projeto pode gerar imprecisões e conflitos contratuais entre as partes envolvidas em projetos industriais.

Assim, a proposta de uma definição mais objetiva das atividades necessárias para a realização do Controle da Qualidade em projetos industriais, permite identificar e medir a eficácia de cada uma das atividades até a aceitação das entregas pelo cliente. Foi desta forma que este trabalho visou agregar ao sugerir uma forma alternativa de definição e sequenciamento de atividades que compõe o processo de realizar o Controle da Qualidade do PMBoK. Isto foi feito através da adição e divisão das atividades, ou um conjunto de técnicas e de ferramentas (Condicionamento, Comissionamento, Partida e Operação Assistida), que antes eram confusamente tratadas como parte integrante um pseudo “Grande Comissionamento”. Se as atividades (Condicionamento, Comissionamento, Partida e Operação Assistida) requerem um conjunto de técnicas distintas para serem executadas, porque não separá-las em atividades independentes para melhor entendimento? Este trabalho está em pleno alinhamento com o PMBoK e apenas visa complementá-lo, assim como o Construction Extension to The PMBoK, para o caso de gerenciamento de projetos Industriais.

Referências Bibliográficas

DE SOUZA, Gil Fábio. Proposta de um Modelo para Gerenciamento das Comunicações na Gestão de Projetos para Empresas de Tecnologia. Florianópolis (SC), Programa de Pós-Graduação em Engenharia de Produção da Universidade Federal de Santa Catarina: Dez/2002 (Dissertação de Mestrado).

GAETE, Luciano; e PRATES, Antonio João. Ferramentas de TI para o Comissionamento de Empreendimentos Industriais. In: Apresentação para XX COPINAVAL – Congresso Panamericano de Engenharia Naval, Transporte Marítimo e Engenharia Portuária. São Paulo (Brasil) realizado no dia 26/Out/2007 (disponível no site da internet: http://www.copinaval.com/downloads/XX/4I/FERRAMENTAS.pdf no dia 14/11/2008).

GANDRA, Rodrigo Mendes. “Comissionamento de Projetos de Oil & Gas (IBP2065_10)”. Anais do Rio Oil & Gas Expo and Conference 2010. Rio de Janeiro (RJ). Instituto Brasileiro de Petróleo, Gás e Biocombustíveis (IBP), 2010.

GANDRA, Rodrigo Mendes: e LOPES, Raphael de Oliveira Albergarias. “Comissionamento como uma Ferramenta do Processo de Controle da Qualidade em Projetos Industriais”. Mundo Project Management, ano 5, n. 30. Curitiba (PR), 15/01/2009, p. 22-27.
INTERNATIONAL ELECTROTECHNICAL COMMISSION (IEC). Commissioning of electrical, instrumentation and control systems in the process industry – Specific phases and milestones. International Standard – IEC 62337:2006(E). Switzerland: 2006.

OPERADOR NACIONAL DO SISTEMA ELÉTRICO (ONS). Estudos de comissionamento de instalações da rede de operação. Sub-módulo 21.3, Revisão 1 de 12/09/2005 (disponível no site da internet: http://www.ons.org.br).

PARODI, Felix J. Lessons From Quantitative Competitive Benchmarking to Impact the Capital Effectiveness of the Latin American Forest, Pulp and Paper Industry. In: 34º Congresso Anual de Celulose e Papel (Associação Brasileira Técnica de Celulose e Papel – ABTCP). São Paulo (Brasil): Out/2001.P

ROJECT MANAGEMENT INSTITUTE (PMI). Construction Extension to The PMBoK Guide Third Edition. USA: 2007 (Second Edition).

PROJECT MANAGEMENT INSTITUTE (PMI). Project Management Body of Knowledge PMBoK. USA: 2008 (Fourth Edition).

SCOTTMADDEN, INC. Project Controls: Managing and Controlling Large Projects. Atlanta (USA): Jan/2009 (apresentação disponível em 03/06/2009 no site: http://scottmadden.com/insight/267/Project-Controls.html).

Autor: Rodrigo Mendes Gandra, MSc, PMP, PMI-RMP, PMA-D

Com o reconhecimento das empresas da necessidade de realizar uma melhor gestão de seus projetos, estruturas vêem sendo desenvolvidas para atender a esta demanda.

O conceito de Project Management Office (PMO) surgiu entre o final da década de 50 e início da década de 60 (KERZNER, 2002) e sua principal função era a aplicação dos conceitos de gerenciamento de projetos dentro da organização.

De sua origem até os dias atuais a síntese de suas funções continua válida, porém, o que mudou foi a relevância dada e esta estrutura dentro da organização, realizando atividades alto valor estratégico, seja implantando e gerenciando o processo de governança, aconselhando executivos ou participando do planejamento estratégico.

Pensando neste aspecto a PM Solutions©, desde 2007, desenvolve o relatório “The State of the PMO” que foi criado para ajudar a compreender a natureza das práticas atuais de um PMO e descobrir as tendências que podem apontar soluções para os desafios de hoje.
Em seu ultimo relatório “The State of the PMO 2010” foram relatadas as dez principais funções de um PMO, que são:

1. Implantação e gestão da metodologia de gerenciamento de projetos
2. Desenvolvimento e gestão das políticas, procedimentos e modelos para gestão de projetos
3. Realização do monitoramento e controle de projetos e programas
4. Treinamento e mentoring em gerenciamento de projetos
5. Planejamento de projetos e programas
6. Coordenação de vários projetos simultâneos
7. Acompanhamento das carteiras de projetos
8. Controle das mudanças e acompanhamento dos problemas
9. Implantação e gerenciamento do processo de governança
10. Encerramento de projetos e programas

Como apresentado, em geral, os PMOs possuem maior foco em funções de gerenciamento de projetos, o que faz sentido e vários desafios significativos para PMOs menos maduros tendem a desaparecer à medida que eles se tornam mais maduros, inclusive demonstrando o valor acrescentado aos projetos.

O relatório “The State of the PMO 2010 – A PM Solutions Research Report” pode ser acessado através do site:
http://www.pmsolutions.com/research/

Para mais informações, acesse:  http://www.pmsolutions.com/

Autor: Autor: Anderson A. Zanett
Fonte: “The State of PMO 2012 – A PM Solutions Research Report” -  http://www.pmsolutions.com/research/
KERZNER, H. (2002) Gestão de Projetos: As Melhores Práticas. Porto Alegre: Bookman.

Segundo Acuff (1993), “a negociação é o processo de comunicação com o propósito de atingir um acordo agradável sobre diferentes idéias e necessidades”. A comunicação, por sua vez, trata-se de um processo que envolve o emissor, a mensagem transmitida e o receptor. Ou seja, a mensagem é a codificação da idéia emitida de acordo com a cultura do emissor e o receptor decodifica de acordo com suas crenças e cultura. Por esse motivo o processo de feedback é tão importante e decisivo para garantir a eficácia no processo de comunicação.

Dessa forma, podemos considerar que a comunicação eficaz é um dos fatores responsáveis para obtenção de sucesso na negociação. Atualmente a habilidade de negociação é essencial para sobrevivência no mundo dos negócios. Por isso é importante observar algumas dicas e práticas para um bom processo de negociação, tais como:

• Ser um bom ouvinte;
• Planejar;
• Mirar alto;
• Ser paciente;
• Justifique a oferta;
• Cautela com a primeira oferta;
• Guarde uma concessão para o final;
• Ter sempre uma alternativa;
• Visar à satisfação;
• Ser ético.

Para James Sebenius (Fórum HSM de Negociação, Set/2010), a negociação envolve bem mais do que se preparar apenas para a fase tática, que é sentar-se a mesa. Ele defende que para alcançar um acordo satisfatório na negociação é necessário agir conforme a estratégia de negociação 3-D, onde o negociador 3-D é:

• Um arquiteto criativo de configurações (fora da mesa);
• Um designer de negócio perspicaz (no flip chart);
• Um tático persuasivo que resolve problemas.

Além disso, ele destaca os passos necessários para construir uma boa estratégia de negociação:

• Faça um mapa das partes e seus respectivos interesses envolvidos;
• Planeje qual seria o acordo possível e o acordo desejável;
• Avalie o que levaria cada parte a abandonar a mesa de negociação, e pense quais seriam as melhores opções de “no-deal” (quando não há acordo);
• Pense na dinâmica de acordo / “no-deal”;
• Anteveja a sequencia da negociação e complete o planejamento;
• Identifique os obstáculos à configuração e ao design do negócio, bem como os obstáculos táticos e interpessoais;
• Formule uma estratégia 3-D para superar os obstáculos.

A necessidade de negociação está presente no dia a dia e em todos os momentos da vida social, tornando-se essencial, principalmente em ambientes de projetos em que lidamos com fornecedores, clientes, equipe, executivos dentre outras diversas partes interessadas.

De modo geral, o futuro negociador precisa constantemente aprimorar suas técnicas e habilidades interpessoais com o intuito de crescimento e aperfeiçoamento juntamente com a satisfação de ambas as partes do processo, pois ser resistente e intransigente não leva a lugar algum e pelo contrário, pode torná-lo retrógrado e alguém mal visto no projeto.

Referências:

PMBOK – 4th Edition
http://www.ricardo-vargas.com/pt/podcasts/feedback_communications/
http://pt.wikipedia.org/wiki/Negocia%C3%A7%C3%A3o
http://www.hsm.com.br/artigos/james-sebenius-tres-dimensoes-da-negociacao
http://www.administradores.com.br/informe-se/artigos/negociacao-conceitos-basicos/34487/

Autora: Cibele Yamanaka
Fonte: E-News do PMI-SP

Artigos Relacionados:

1. Comunicação: Ouvir, Entender e Falar
2. Dicas para ajudar você a gerenciar a competição de prioridades dos projetos
3. Excelência na gestão de projetos através da comunicação eficaz com stakeholders
4. Comunicação é Causa de Problemas em Projetos
5. A Comunicação na Gestão de Projetos