Segue a descrição do evento:

Introdução:
Atualmente o Gerenciamento de Serviços de TI tornou-se um fator crítico dentro e fora da TI. Ter conhecimento sobre os diversos frameworks, boas práticas e normas, sobre a aplicabilidade de cada um dentro de uma organização e seus benefícios é de extrema importância para os profissionais desta área. Participe deste Webinar e obtenha uma visão geral sobre os mais conhecidos frameworks e normas utilizadas mundialmente nas organizações.

Objetivo:
Apresentar os frameworks e normas mais utilizados ao redor do mundo como: ITIL®, Cobit, CMMI, Green IT, Cloud Computing, Business Information Management (BIM®), Normas ISO/IEC 20000 e 27000), etc, bem como seus benefícios e área de aplicação dentro das organizações.

Público alvo:
Profissionais de TI e fora de TI que já atuam ou queiram atuar na área de Gerenciamento de Serviços de TI e desejam ter uma visão integrada dos principais frameworks disponíveis no mercado.

Palestrante – Marcos Sabino Gomes
Consultor de Governança de TI da High IT que possui certificações como ITIL Expert, ISO 20000, ISO 27002, BIM®, Cloud Computing, que já atuou em diversos segmentos como finanças, manufatura e serviços, efetuando avaliação, desenho e implementação dos processos e normas relacionadas à TI, aplicando diversos treinamentos relacionados ao tema.

Inscrição gratuita: Para garantir a participação no evento clique em Register do lado esquerdo da tela neste site da Exin –  http://bit.ly/JWIgvW

Roberto Fabiano Fernandes

Paulo Maurício Selig

Universidade Federal de Santa Catarina.

RESUMO

Para que as estratégias das organizações se tornem realidade, ou seja, que se transformem em produtos, sejam bens ou serviços, que atendam aos stakeholders, uma pessoa deve ser designada para gerir as ações necessárias. Mas qual o perfil necessário e quais habilidades que esta pessoa deve possuir para conseguir transformar a estratégia em realidade? Partindo destas indagações, a metodologia deste trabalho, se deu por intermédio de buscas exploratórias sobre o tema na forma de revisão bibliográfica abrangendo artigos, periódicos e publicações que estejam relacionadas com o assunto deste trabalho. Resultando na discussão sobre a visão do perfil necessário ao profissional que atua na gestão de projetos, seus papéis, responsabilidades, competências: conhecimentos, habilidades e atitudes.

Palavras-chave

Competências; Gestor de Projetos; Líder de Projetos; Gerente de Projetos; Chefe de Projetos.

1. INTRODUÇÃO
No contexto atual, altamente competitivo e globalizado, onde as organizações procuram estar à frente no seu segmento, ou se manter no mercado, cada vez mais faz-se necessário obter diferencial competitivo. Sendo assim, as organizações passam a ter que aprimorar continuamente suas estratégias de gestão, bem como transformar estas estratégias em produtos, sejam bens ou serviços, que atentam de forma eficiente e eficaz os seus stakeholders.

Para tal, a criação de portfólios, programas e projetos é extremamente recomendada (PMBOK[1], 2008; PMI[2], 2008a; PMI[3], 2008b). Entretanto, para que se tornem realidade, uma pessoa deve ser designada. Qual o perfil necessário? Qual o papel que deve representar? Quais habilidades que esta pessoa deve possuir para conseguir transformar a estratégia em realidade?

Em busca de respostas para estas indagações utilizamos da metodologia de pesquisa para ajudar a aclarar a visão em relação ao profissional de projetos, a qual será descrita no tópico seguinte.

2. Metodologia
Este tópico apresenta os procedimentos metodológicos que norteiam a implementação dos objetivos deste artigo, formando o delineamento da pesquisa.

A metodologia é uma preocupação instrumental onde, segundo Gil[4] (2010), são realizadas etapas metodológicas baseadas em elementos conceituais e técnicas de pesquisa. O autor complementa o pensamento anterior afirmando que o método científico de uma pesquisa pode ser definido como um caminho para se chegar ao fim de um determinado trabalho, de forma que se consiga atingir os objetivos inicialmente propostos.

Quanto à caracterização, este trabalho será analisado pela sua natureza, abordagem, objetivos e pelas técnicas utilizadas.

Quanto à natureza é considerada uma pesquisa aplicada, pois seu objetivo é voltado à aquisição de conhecimentos com vistas à aplicação numa situação específica (GIL, 2010).

Adota-se uma abordagem qualitativa, pois envolve compreensão de um evento em seu ambiente natural; trabalho de campo e resulta em um produto descritivo (MERRIAN[5], 1998).

Quanto aos objetivos é uma pesquisa exploratória, pois envolve pesquisas bibliográficas. Gil (2010) define a pesquisa exploratória como:

Estas pesquisas têm como objetivo proporcionar maior familiaridade com o problema, com vistas a torná-lo mais explícito ou a constituir hipóteses. Pode se dizer que estas pesquisas têm como objetivo principal o aprimoramento de ideias ou a descoberta de intuições. Seu planejamento é, portanto, bastante flexível, de modo que possibilite a consideração dos mais variados aspectos relativos ao fato estudado. Na maioria dos casos, essas pesquisas envolvem: (a) levantamentos bibliográficos; (b) entrevistas com pessoas que tiveram experiências práticas com o problema pesquisado (…) (GIL[6], 2010, p. 27).

Quanto à pesquisa bibliográfica, Gil (2010, p. 29) diz que é desenvolvida com base em material já elaborado, constituído principalmente de livros, artigos, periódicos e publicações que estejam relacionadas com o assunto deste trabalho, sendo preferidos os mais recentes.

Seguindo estes procedimentos metodológicos obtiveram-se os materiais considerados necessários para a fundamentação dos tópicos a seguir.

3. GESTOR, GERENTE, LÍDER, CHEFE?
Muitos são os termos utilizados pela literatura para tratar da pessoa responsável por transformar os objetivos estratégicos, da organização, em produtos com resultados exclusivos. O Project Management Institute (PMI), a principal associação mundial de gerenciamento de projetos, em suas três principais obras, designa esta pessoa como Gerente, mas atribui a esta, diferentes papeis e responsabilidades desassociadas ao cargo em que esta pessoa ocupa, ou seja, para ser um gerente de projetos, por exemplo, não faz-se necessário que a pessoa tenha o cargo de Gerente (PMBOK[7], 2008; PMI[8], 2008a; PMI[9], 2008b). O que pode levar a certa confusão, como ser gerente sem ter cargo de gerente na organização? Sendo assim, algumas organizações denominam este profissional não como Gerente de Projetos, mas como Gestor de Projetos, Líder de Projetos ou Chefe de Projetos.

Ao recorrer para a definição dos termos Gestor, Gerente, Líder e Chefe, se tem respectivamente:

• Gestor: Indivíduo que, sem mandato, administra negócios alheios (MICHAELIS[10], 2009).
• Gerente: Que, ou quem gere, dirige ou administra bens, negócios ou serviços (MICHAELIS, 2009); Por sua vez Lacombe[11] (2004) define o termo como sendo: Pessoa responsável pelos trabalhos e pelos resultados de um órgão, ou uma equipe que exerce, portanto, as funções de administrador.
• Líder: Tipo representativo de um grupo (MICHAELIS, 2009). “O líder cria nos liderados a sensação de um espaço próprio, onde eles podem desenvolver sua criatividade e se auto realizar na execução de suas tarefas” (MOTTA[12], 2007). Não necessariamente um líder precisa ter a autoridade do cargo.
• Chefe: Indivíduo que, entre outros, tem a autoridade ou a direção. Empregado ou funcionário encarregado da direção ou supervisão de uma seção, departamento, repartição, etc. (MICHAELIS, 2009). Ou seja, o chefe tem a autoridade estabelecida pelo cargo que ocupa na organização.

A literatura não aponta uma consolidação, uma diferenciação entre os termos gestor e gerente, em língua inglesa os termos tem a mesma palavra manager, no entanto percebe-se uma diferenciação na prática entre o papel e reponsabilidade destes no Brasil. No primeiro setor da economia, por exemplo, tem crescido muito o uso da terminologia gestor, que se refere a pessoa que gere processo, atividade ou tarefa em si. Não necessariamente o gestor tem subordinados. O termo gestor, também esta sendo gradativamente adotado nos demais setores da economia uma vez que este, não está diretamente associado ao nível tático da estrutura organizacional, podendo exercer o papel em qualquer um dos três níveis seja estratégico, tático ou operacional. Entretanto, o gerente está mais associado a uma hierarquia em nível tático.  As características desta diferenciação pode ser mais bem visualizada no quadro 1.

QUADRO 1 – DIFERENÇAS ENTRE GESTOR E GERENTE

Fonte: Autores, dados de pesquisa.

Contudo, a literatura distingue exaustivamente uma diferenciação entre Líder e Chefe, indicando fortemente que todos os colaboradores que possuem subordinados deveriam ter atitudes de líderes e não chefes, conforme pode ser percebido no quadro 2, que faz a distinção destes.

QUADRO 2 – DIFERENÇAS ENTRE GESTOR E GERENTE

Fonte: Pacheco e Silva Neto[13] (2011).

Neste ponto, vale destacar que o profissional de projetos deve ter as características relatadas neste trabalho como as de gestor e líder e estas, não são mutuamente exclusivas.

Newton[14] (2011) destaca que o gestor de projetos é a pessoa responsável em entregar todos os componentes de um projeto. O autor ainda destaca que a função de gestor de projetos pode ser de tempo parcial ou integral. Quanto ao trabalho varia de projeto a projeto, mas basicamente a responsabilidade é de se estabelecer um escopo e ater-se a ele, de forma a planejá-lo e gerencia-lo com base em uma metodologia que ajude a garantir o escopo, o prazo, a qualidade e o tempo acordado. Desta forma, entende-se que ele lidera a sua equipe para atingir os objetivos traçados de forma estratégica ao projeto.

Sendo assim, a denominação que mais se a adequa ao profissional de projetos no contexto brasileiro, segundo este estudo é de Gestor de Projetos, afinal a importância esta associada a tarefa de gestão do projeto e não no cargo propriamente dito.

4. GESTOR DE PROJETOS, PAPÉIS RESPONSABILIDADES, COMPETÊNCIAS: CONHECIMENTOS, HABILIDADES E ATITUDES.
O gestor na área projetos pode ter alguns papéis bem definidos como gestor de portfólios, programas e projetos bem como de um escritório de projetos. Em inglês os temos são respectivamente: Portfolio Manager, Program Manager, Project Manager e Project Management Officer (PMO). Todas estas funções tem em comum o fato de que a pessoa em questão deve ter habilidades de gestor e liderança. O que difere para haver esta segmentação são os objetivos relacionados à função. No contexto brasileiro muitas organizações não fazem a distinção da nomenclatura, chamando-os de gerente de projetos.

O gerente está associado a um determinado departamento em uma matriz funcional, cabe ao gerente manter a ordem e gerenciar os processos organizacionais de sua área, departamento ou setor dentro da estrutura da empresa. O papel do gestor no contexto de projetos pode ir além, pois não necessariamente se atem a um departamento, setor ou área da empresa. Ele pode gerir de forma a envolver varias áreas da empresa de maneira transversal. A figura 1 apresenta esta visão da dissociação do cargo de gerente da ação de gerir um projeto, nela denominada de gerente do projeto. Pelo fato do gestor deste projeto não ter o cargo de gerente.

Figura 1 – Gestor de projeto em uma matriz organizacional fraca

Fonte: PMBOK[15] (2008).

4.1. Papéis e Responsabilidades

Os Gestores de Portfólio tem como objetivo, fazer com que os objetivos estratégicos da organização se tornem realidade. Caso haja alguma mudança na estratégia da empresa durante o percurso da execução deste portfólio, este gestor é responsável que os projetos, programas, portfólios e outras ações que compõe o portfólio desta estratégia em questão, se adequem a esta mudança. Cabe ao Gestor de Portfólio receber informações sobre o progresso e o desempenho de componentes, transmitir ao board, ou seja, ao conselho administrativo, como os componentes, como um todo, estão alinhados com os objetivos estratégicos e fornecer recomendações apropriadas ou de opções de ação, em caso de necessidade de um realinhamento às estratégias. Os Gestores de Portfólio também devem garantir que o cronograma de todos os componentes que fazem parte do portfólio seja mantido e seguido pelos demais Gestores de Projetos, Programas e outros trabalhos (PMBOK[16], 2008; PMI[17], 2008a; PMI[18], 2008b).

O Gestor de Programa é responsável por garantir que a estrutura geral do programa e a estrutura dos processos de gestão do programa, permitam que as equipes relacionadas a este possam completar com sucesso o seu trabalho, entregando os componentes de forma integrada no produto final. Os Gestores do programa também devem garantir que os projetos sejam organizados e executados de forma consistente e/ou cumpridos dentro dos padrões estabelecidos (PMBOK, 2008; PMI, 2008a; PMI, 2008b).

O Gestor de Projeto é responsável pelo planejamento, execução, monitoramento e entrega dos projetos à ele atribuídos de acordo com os objetivos e as especificações correspondentes. Ao Gestor de Projeto cabe fornecer indicadores de desempenho do projeto, direta ou indiretamente, ao conselho administrativo, ao Gestor de Programas, ao Gestor de Portfólio ou ao PMO. Estas informações serão usadas com outros critérios para determinar quais projetos serão continuados. O Gestor de Projeto podem também fornecer um plano de recuperação para projetos em perigo e ser responsável pelo orçamento e cronograma de todos os projetos atribuídos (PMBOK, 2008; PMI, 2008a; PMI, 2008b).

O PMO suporta os Gestores seja de Projeto, Programa ou Portfólio, fornecendo as informações necessárias para tomar decisões que os orientam e fornecendo apoio administrativo na gestão de cronogramas, orçamentos, riscos e outras áreas necessárias para gestão eficaz. As responsabilidades de um PMO podem incluir as seguintes: prestação de funções de apoio à gestão de projetos; gestão do dia-a-dia das operações do sistema ou sistemas de apoio que a gestão da carteira, recursos e; gerenciar diretamente um componente ou categoria de componentes. (PMBOK, 2008; PMI, 2008a; PMI, 2008b).

Em cada um destes papéis, os Gestores devem tomar decisões estratégicas. Estas têm cunho interdisciplinar (PORTER[19], 1980; CHOO[20], 1996; DAVENPORT[21]; PRUSAK, 1998; NONAKA[22]; TAKEUCHI, 1997; NONAKA[23] et al., 2000) ao decidir: que tipo, forma e maneira que se devem desenvolver os entregáveis, o que pode envolver várias áreas de negócios dentro de uma organização, vários conhecimentos, habilidades, técnicas e atitudes, interagindo com diversos stakeholders (FORCELLINI[24], 2010).

Para conseguir alcançar os objetivos, os gestores devem interagir com os stakeholders, gerenciando suas expectativas e entregando produtos, sejam bens ou serviços que atendam a estas expectativas dentro do tempo, custo, escopo e qualidade. Esta interação se dá por intermédio dos conhecimentos, habilidades e atitudes deste gestor.

4.2. Competências: Conhecimentos, Habilidades e Atitudes.

Perrenoud[25] (2000) define competência como a mobilização de múltiplos recursos cognitivos (saberes, informações, valores, atitudes, habilidades, inteligências, esquemas de percepção, de avaliação e de raciocínio). As competências, segundo Rabaglio[26] (2001), podem ser técnicas ou comportamentais. As primeiras competências referem-se as habilidades, portanto levam tempo. Só experiência não basta para elas, será preciso estudo contínuo. Já as competências comportamentais funcionam muito bem quando se têm elas na personalidade. Isso não significa que não possam ser aprendidas com um pouco de disciplina. Fonseca[27] (2003) acrescenta mais um tipo de competência sob o ponto de vista individual. São as competências estratégicas, que podem ser classificadas em gerenciais, técnicas e sociais. Essas competências são as que movem a empresa sendo, portanto, as competências mais desgastantes, pois requerem a maior parte da energia do gestor, do líder ou do gerente de projetos.  Portanto quanto mais conhecimento existir nesta área, mais potência a empresa terá.

Competências, habilidades interpessoais são esperadas de um gestor para gerenciar as expectativas das partes interessadas (PMBOK[28], 2008). Estas competências, conhecimentos, habilidades e atitudes devem extrapolar a disciplinaridade, afinal fazer uma gestão eficaz e eficiente envolve uma gama de saberes das mais diversas áreas como da administração, engenharia, psicologia, dentre outras, Ferenhof[29] et al. (2011).

Segundo Masetto[30] (2004), o conceito de interdisciplinaridade apresenta um paradigma de conhecimento e de ciência que ultrapassa o modelo tradicional de se conhecer. A interdisciplinaridade nos permite esperar a produção de um conhecimento científico novo a partir de duas ou mais diferentes áreas de conhecimento que se integram para tal.

Os gestores devem ter as atitudes de líderes, onde “o líder é o indivíduo capaz de canalizar a atenção dos participantes e dirigi-las para ideais comuns” (MOTTA[31], 2007). O quadro 3 aponta as atitudes, conhecimentos e habilidades que um Gestor deve possuir.

Quadro 3 – Atitudes, Conhecimentos e Habilidades de um Gestor de Projetos.

Fonte: Ferenhof et al. (2011).

Com base no quadro 3, é possível identificar características de profissionais que tenham as competências, ou seja, os conhecimentos, habilidades e atitudes necessárias para gerir projetos, bem como identificar em quais dos pontos elencados o profissional esta capacitado e, em quais o mesmo necessita de melhoria, direcionando os esforços para capacitar o profissional para melhor atuar como gestor.

5. CONSIDERAÇÕES FINAIS
Este artigo traz a tona uma discussão sobre o perfil necessário ao profissional que atua na gestão de projetos, seus papéis, responsabilidades, competências: conhecimento, habilidades e atitudes, procurando desmistificar os termos adotados nas organizações para designar o profissional de projetos. Também procura esclarecer que o Gestor de Projetos não necessariamente precisa ter um cargo de Gerência. Por fim, procura enfatizar que diferentes papéis e responsabilidades são esperados deste Gestor na organização, bem como as competências: conhecimento, habilidades e atitudes interdisciplinares necessárias ao profissional de projetos, devido à diversidade de ambientes, culturas, situações e pessoas envolvidas.

O artigo busca também complementar a visão do profissional de projetos como Gestor e Líder no qual gere grupo de processos, um processo, atividades e/ou tarefas em si, de maneira a guiar e entusiasmar seus liderados, sem barreiras, vibrando com o trabalho em equipe e com o êxito coletivo. Bem como, quais são as competências: conhecimentos, habilidades e atitudes necessárias a este profissional para exercer uma gestão eficiente e eficaz, possibilitando ainda ter indicadores para um diagnostico deste profissional, elencando os pontos fortes e fracos, respectivamente a serem mantidos e, melhorados.

6. REFERÊNCIAS

Requisito pode ser definido como qualquer capacidade ou característica mensurável do resultado final do projeto, seja ele um produto ou serviço. No nosso contexto (vamos focar em projetos de tecnologia – sistemas), estamos então falando de funcionalidades, capacidades e características de sistema entregue. Ou seja, de forma bem simples, os requisitos descrevem o que o sistema fará e como fará. Importante: o “como” é sob a ótica de quem usa, não de quem constrói.

A documentação de requisitos é a base para a definição do escopo do projeto, permitindo a conversão dos desejos e expectativas dos clientes em itens mensuráveis e rastreáveis. Apoiará também o controle de mudanças no projeto, o rastreamento do atendimento aos requisitos, além de ser a base para se obter uma aprovação formal do resultado final. Enfim, é um importante instrumento de planejamento, gerenciamento e de relacionamento com o cliente.

Assim, vamos a algumas dicas úteis para se definir e gerenciar os requisitos de um projeto:

• Identifique todos os envolvidos do projeto. Stakeholders são aquelas pessoas envolvidas ou afetadas pelo projeto. Identificá-los permitirá que você possa investigar suas necessidades, expectativas e desejos. Pessoas “esquecidas” em fases iniciais poderão surgir mais à frente e seus requisitos precisarão ser incorporados. Isso significa possíveis mudanças de escopo. E isso pode significar atraso no cronograma e aumento de custos.

• Documente todos os desejos e expectativas destes stakeholders. Aqui o trabalho é de detetive. Faça reuniões, entrevistas, aplique questionários, faça sessões JAD, brainstorms, etc. Use as mais variadas técnicas para colher todas as informações sobre as características desejadas.

• Associe os requisitos aos stakeholders. Quem é o dono de cada requisito? É importante que você consiga estabelecer essa relação, pois a gestão das mudanças no projeto começa aí. Qualquer pessoa pode solicitar qualquer alteração, em qualquer ponto? Não se esqueça de obter a aprovação dos requisitos antes de começar a construir.

• Transforme desejos em requisitos. “Quero um sistema mais veloz.” “Quero um software mais amigável.” “Desejo maior usabilidade.” “Espero maior integração.” Nenhuma dessas frases (e seus resultados) é mensurável. Um sistema com um desempenho 0,00005% melhor é “mais rápido”, não é mesmo? No entanto, é isso que o cliente espera? Ou seja, traduza os desejos em itens que possam ser medidos e avaliados, como capacidade de processamento, capacidade de armazenamento ou características específicas de interface, por exemplo.

• Atenção à descrição. Essa dica anda casada com a anterior. Alguns termos que você não deverá nunca usar: “veloz, rápido, amigável, fácil, suportar, etc, ou, mas não limitado a, minimizar, maximizar, suficiente, adequado, estado da arte”. Essas expressões não dizem nada!

• Classifique os requisitos. Reúna-os em grupos como, por exemplo, obrigatórios (sem eles o sistema não entra em funcionamento), importantes (o sistema entra em funcionamento sem eles, mas com capacidade limitada) e desejáveis (são interessantes, mas, num quadro geral, não comprometem a utilização do sistema).

• Associe os requisitos aos produtos gerados pelo projeto. Aqui, já estamos falando de gerenciamento de escopo. Se um requisito não está associado a algum produto, para que está sendo atendido?

• Reporte o atendimento aos requisitos durante o projeto. Ou seja, informe para aqueles donos sobre o atendimento aos seus requisitos. Obtenha a aprovação quando cada entrega parcial (se houver) for realizada e quando a entrega final do projeto for realizada também.

Seguindo essas dicas, muitos problemas comuns em projetos de tecnologia poderão ser evitados. Torne essa atividade sistemática em seus projetos. Mas isso não significa que deva ser burocrático! E lembre-se de que a forma da sua documentação não deve ser mais importante que seu teor. Post-its e anotações em quadros brancos, uma vez validados como métodos adequados para seu contexto, estão valendo.

A necessidade de alinhar objetivos e estratégias da organização à execução de portfólios, programas e projetos não é uma tarefa trivial. Comunicar esta estratégia de forma eficiente e torná-la eficaz é um desafio constante para as organizações.

Alinhada a esta demanda organizacional, a implantação de Escritórios de Gerenciamento de Projetos (PMO – Project Management Office) cria mecanismos que irão permitir acompanhar e monitorar se os projetos executados estão alinhados às estratégias das organizações, por exemplo.

Mas seria só este o papel do PMO na organização?

 Definindo um Escritório de Gerenciamento de Projetos (PMO)

Existem várias definições para o Escritório de Gerenciamento de Projetos, que de certa forma se convergem /complementam, tais como:

• Rad & Raghavan (2000) uma entidade organizacional que provê o foco institucional nos procedimentos de gerenciamento de projetos;
• Crawford (2000), como um provedor de serviços e processos completos para gerenciamento de projetos e que o mesmo também atua como centro de excelência em gestão de projetos dentro da organização;
• Cleland & Ireland (2000) como grupo de suporte que provê serviços para os gerentes de projetos, gestores seniores e gerentes funcionais trabalhando em projetos;
• Kate (2000) define o Escritório de Gerenciamento de Projetos como uma unidade do negócio focada na eficiência do gerenciamento de projetos e programas dentro da organização;
• Kerzner  (1992) diz que o time do projeto é uma combinação do Escritório de Gerenciamento de Projetos e os empregados funcionais.

Por exemplo: Submeta para aprovação do cliente um cronograma, projeto, orçamento de horas ou seja lá qual for o nome que você dá para aquele documento com prazos para o desenvolvimento de um sistema. Clientes em universos paralelos podem questionar você que 16 horas é muito tempo para a criação de uma feature qualquer, ainda que ela seja complexa. Diz que é possível fazer em 8 horas tranquilamente. Vejam, 16/8, é a tal proporção 2/1 que citei. Clientes em universos paralelos mais velozes podem sugerir que o tempo caia de 16 horas para 4 horas, afinal é só uma tela. Ou seja, este universo tem uma proporção de tempo de 4/1 se comparado com o universo normal, onde nós desenvolvedores mortais vivemos. É um universo Speed Racer.

Outros clientes vivem em universos com peculiaridades complexas na estrutura temporal. Nós, desenvolvedores mortais temos freqüentemente dificuldade em compreender tal lógica que desafia todos os conceitos da física. Por exemplo, certa vez estava trabalhando no tunning de um sistema que ajudei a desenvolver. O sistema permitia que uma certa atividade pudesse ser feita em lotes de itens cujo tipo não vem ao caso aqui. Então o usuário preparou uma planilha com os tempos atuais da atividade quando um item, quinze itens ou trinta itens eram submetidos. Vamos dizer que o resultado foi 1x, 15x e 30x. Obviamente todos insatisfatórios no rápido e misterioso universo em que eles vivem. Ao lado desta tabela, havia outra com os tempos esperados. Eles queriam que um item levasse 0,5x tempo. Até ai tudo bem. O problema era que quinze itens deveriam levar não 7,5x como esperado, mas sim 5x. E trinta itens deveriam levar 8x e não 15x. Ou seja, quanto mais itens processados, menor era o tempo individual de cada um, eles tendiam a zero. Se conseguísse atender o cliente, talvez se eu processasse milhões de itens eu conseguiria fazer o tempo correr ao contrário. Não fiz este teste porque eu poderia abrir um buraco negro ou alguma coisa assim e hoje você não estaria lendo isso.

Há ainda universos onde parar o tempo é algo corriqueiro. Suponha que seu cliente tenha aprovado seu cronograma e depois se lembrou de outra feature que ele quer no aplicativo. Ele não aceita mudar o prazo final, não aceita pagar horas extras para o desenvolvimento e não aceita pagar por mais recursos no projeto. Ele insistirá que dá para encaixar a tal feature no projeto sem comprometer o bolso dele e o prazo final. O que me leva a crer que no universo onde ele vive é possível parar o tempo, desenvolver a feature e depois soltar o tempo para que ele corra novamente.

Clientes são pessoas com estas e outras incríveis capacidades físicas que me admiram a cada contato e projeto novo. Há sempre algo surpreendente e desafiador por trás de cada solicitação em um projeto.

A ferramenta chega para agregar conhecimento, exposição ao mercado, oportunidades de negócios, empregos, divulgação de eventos e muito mais.

O Forum é dividido em áreas de conhecimento tais como Gestão de Projetos, Desenvolvimento, Governança Corporativa e E-Commerce.

Com esta ação o TI Especialistas espera dobrar seu “Market Share” em um curto espeço de tempo. Novas ações também estão sendo desenvolvidas com várias empresas parceiras.

Aguardem!

Acessem o Forum e inscrevam-se: www.tiespecialistas.com.br/forum/

Forum - TI Especialistas

1. Em projetos ágeis não é necessário fazer uma grande entrega no final do projeto. É possível e desejável que se faça pequenas entregas com a possibilidade do cliente iniciar o uso imediato do que já foi entregue. Isso por si só já leva a uma maximização do ROI dado que o projeto já pode ser usado enquanto novas funcionalidades são criadas. Cada nova entrega pode trazer um pouco de retorno.

2. Como podemos e devemos fazer pequenas entregas, em projetos em que os métodos ágeis são usados, a tendência natural é ignorar os itens que não geram valor. Estudos mostram que somente 20% das funcionalidades são usadas sempre ou frequentemente e 64% das funcionalidades são desperdício.

Isto tudo também faz com que o projeto tenda a ser finalizado antes, liberando os recursos para outras demandas.

3. Em  projetos tradicionais, a mudança de escopo não é bem-vinda, mas em métodos ágeis, as mudanças são bem-vindas, principalmente, quando elas levam a uma melhor adaptação do projeto às necessidades de negócio com definição de prioridades entre elas.

Será que não podemos fazer várias pequenas entregas no lugar de uma grande entrega?

Será que o escopo não pode ser alterado?

Será que as funcionalidades não podem ser reordenadas?

Métodos ágeis representam sim e muito uma quebra de vários paradigmas em relação a forma de como os projetos são conduzidos tradicionalmente e  isso pode ser muito bom se bem utilizado.

No entanto este conhecimento é uma arma importante, mas ao mesmo tempo alia-nos a uma responsabilidade muito grande na gestão de projetos e gestão de recursos, acabando desta forma por ser uma arma terrível, pois exige da nossa parte grande desgaste e muito pouco tempo para conseguir gerir o dia a dia.

Nem sempre toda as pessoas com este perfil, que requer ter uma grande capacidade na gestão do dia a dia, entre e-mail, reuniões, gestão de recursos e acompanhamento de projetos, é reconhecimento pelas respectivas chefias, o que por muitas vezes nos deixa num certo desconforto, quando nos consideram por muitas vezes como sendo simples técnicos, quando o nosso valor junto das áreas de negócio é visto como uma parceria muito válida, no que á definição e acompanhamento dos requisitos de negócio diz respeito, sendo considerada por estes como fundamental.

O sucesso dos nossos gestores depende do nosso sucesso, e por muitas vezes esse valor não é reconhecido, mas enfim, um bom profissional fica sempre satisfeito com o bom trabalho desempenhado, ou seja, pelo menos alimenta o ego de dever cumprido.

A alienação de tarefas por vezes é muito difícil de gerir, pois os projetos decorrem à velocidade da luz e em simultâneo nas diversas área de produtos e serviços em que nos encontramos inseridos, o que por muitas vezes temos de trabalhar em diversas frentes e com equipa de consultoria diferentes, não deixando muita margem na gestão do dia a dia.

No mundo da informática e do negócio bancário posso simplesmente afirmar que trabalhar e ter o conhecimento na área de cartões bancários é muito bom, pois qualquer produto que abranja uma utilização ao nível mundial é simplesmente magnifico, perceber o bit e o bite deste negócio é muito reconfortante, sabendo acima de tudo que se trata de um produto lucrativo para o negócio, pelo que o investimento no desenvolvimento de novos produtos de cartões e novas funcionalidades, deve sempre ser uma aposta, dependendo do conhecimento e apostas na cultura dos seus utilizadores.

Resolvi este pequeno dilema inicial ao ler, mais uma vez, o “Poema em Linha Reta” de Álvaro de Campos (heterônimo de Fernando Pessoa). Se você ainda não leu, leia.

O poema já começa de uma forma instigante:“Nunca conheci quem tivesse levado porrada. Todos os meus conhecidos têm sido campeões em tudo.”

Portanto resolvi me juntar ao Álvaro de Campos e em vez de falar sobre o que poderia ser feito ou sobre um modelo de qualidade ou até um case de sucesso, falarei sobre um fracasso retumbante.

Antes de iniciar, um pouco do que está por trás do meu currículo: sou formado em Engenharia da Computação com Ênfase emEngenharia de Software na UMESP.

Tenho alguns bons anos nesta caminhada junto às boas práticas, modelos de qualidade e frameworks. Já implantei CMM, CMMI, MPS.BR e ISO. Já participei de projetos com o objetivo de implantar processos face ao que prega a biblioteca ITIL e na implantação de Escritório de Projetos. Obtive as certificações ITIL e CObIT Foundation em um período de um mês. Obtive a certificação PMP e depois obtive a certificação ITSM (também chamada, informalmente, de ITIL Master ou apenas ITIL Manager).

Mas nada disso, experiência, background acadêmico e certificações, impediu que eu cometesse os mais básicos dos erros: não definir bem o escopo, não gerenciar os riscos e não gerenciar stakeholders.

Primeiro projeto na empresa (sem datas/nomes), único PMP do PMO e com a missão de gerenciar um projeto de melhorias em sistema existente. Não era um sistema complexo, pois ele não tinha uma montanha de regras de negócio, era muito conhecido (demandante usava o sistema cotidianamente) e o fornecedor escolhido para construir tinha um histórico muito bom em projetos passados. Piece of cake, diriam os americanos.

A coisa começou a desandar quando o fornecedor perdeu um dos seus líderes técnicos, restando outro, competente, mas que se viu com vários projetos na mão. Depois a organização perdeu um líder técnico e que desenvolvia também, responsável por outro projeto no mesmo sistema. O meu projeto incorporou os requisitos que faltavam serem desenvolvidos do dele.

Foi quando caí na armadilha mais básica de todas: fui resolvendo os problemas entrando em acordo com os stakeholders sem documentar nada e fui descobrindo que a área que deveria conhecer o sistema, pois era usuária principal, tinha acabado de mudar de comando. Portanto o gestor e o seu time não conheciam tão bem assim. Já o fornecedor, corresponsável pela documentação, estava equilibrando vários pratos e acabou não documentando nada também.

O resultado disso foram as constantes discussões para estabelecer as regras, defini-las corretamente, ou corrigi-las. Tudo isso sem documentação sendo atualizada. Os impactos não foram avaliados corretamente, tínhamos uma dependência de um sistema externo de uma empres apública, que entrou em greve, tivemos constantes trocas de requisitos e tudo isso só na palavra, o que para mim era o suficiente.

Para mim. Para alguns outros não é, portanto um stakeholder começou a pedir mais coisas do que havíamos combinado e sempre perguntava, quando eu dizia que não fazia parte do escopo, onde isso estava escrito.

O projeto simples virou um bicho-de-sete-cabeças. Atrasou muito, o fornecedor teve estresses e “sujou” seu passado, pois acabou atrasando outros projetos também, eu me estressei com o projeto e com a área demandante, não tive o apoio necessário da alta gerência e ainda me vi obrigado a ouvir “ué, você não é PMP?”. Sim, sou, mas não sou perfeito e nem mágico.

Eu poderia jurar que já sabia estas lições aprendidas, mas pelo visto ainda não havia absorvido. Não adianta você ser um ás da negociação se não documentar tudo, não adianta pular etapas só porque você julga que o projeto será simples, entenda bem os stakeholders para saber gerenciá-los, fechar e defender o escopo é uma arte necessária e gerenciar riscos é fundamental. No mínimo é isso que precisamos tirar do fracasso. Uma lição para não repeti-lo mais.

Depois deste projeto eu aprendi e absorvi: o projeto seguinte foi um sucesso.

“O milho não é perene, é? Só dá para uma safra para nunca mais. É gostoso…”.

“Ele grita tremendamente, acaba estourando e em seguida estabelece um silêncio. É assim mesmo o milho de pipoca é barulhento, se em contato com o fogo”, completou o vitelo.

A manada ignorou a tentativa de discurso da bezerrada. Antes mesmo de o sol virar para o oeste, apareceu um Tigre assustado para selecionar os touros para labuta em regime extraordinário.

“Hoje precisamos carregar a soja para exportação, o navio está atracado aguardando a carga, ninguém vai para casa antes de terminar o serviço”.

Ele era líder do grupo, tinha que coordenar as atividades de exportação da soja para o além-mar. Não aceitava pestanejação, a não ser que o touro quisesse virar janta do Leão, chefe mor. Era experto o suficiente para não desejar ser refeição. Seu desejo estava por se realizar, viajar. Isso só aconteceria na aposentadoria. Os animais pararam de mastigar. O silêncio reinou novamente.

“Tudo bem! Darei a vocês uma recompensa por todo esse esforço. Que tal um descanso triplo, vocês terão três dias de descanso ”, concluiu o Tigre num tom misto de democracia e intimação, como se alguém pudesse dizer que não quer trabalhar. Essa opção não existia, embora parecesse. Era ordem mesmo lá de cima, como gostava de dizer para selar a necessidade de participar.

A noite parecia ter chegado para aquela espécie. O sol que se fazia deitar nas costas era lua naquele momento. O clima mudou drasticamente, nem o novilho que gritava para mamar foi suficiente. Pareciam desprovidos de audição. Ninguém tinha chance de curtir o silêncio, o ar fresco que soprava se transformara em bafo quente.

“Hoje tenho compromisso”, argumentou o Touro marrom.

“Hoje é aniversário dela minha…”, comentou outro, sem vontade de fazer-se entender.

“Pois é, colegas. Vocês tinham todos esses compromissos, sei… Agora há um compromisso muito maior, que é carregar a soja.” Ordenou o Tigre em tom ameaçador.

Um mosquito atrevido posou sobre o nariz do Touro Cinzento, sugando-o. Ele despertou atordoado, deu meia volta roçando sobre a árvore. Tropeçou, perdeu o equilíbrio e tombou, cai escandalosamente. Seus olhos pareciam desgostados, a lingua à vista. Começou a escutar vozes infinitas de bezerros e vacas, sem mesmo saber a procedência. O zumbido aumentava, ouvia vozes que diziam “seja bem vindo, papai. Nós amamos você”. Concentrou-se. Gostou. O Tigre não perdeu tempo chutou o Touro, dizendo.

“Cada fera que me aparece, levanta-te e mãos a obra. Daqui ninguém sai enquanto não terminar. Ai de quem ousar desobedecer… Estará  jogando fora a sua empregabilidade.”

Um olhar furioso se vez presente, mas imediatamente empenharam-se em executar a tarefa, sob a chuva dos falares e murmúrios do Tigre que, a qualquer custo, queria ver a soja embarcada para além-mar.

O carregamento terminou às cinco horas da manhã. No dia seguinte alguém queria usufruir os três dias que foram prometidos. Foi então que a voz do Tigre sumiu. Ficou quieto como uma criança em fase de observação para aquisição da linguagem. Não houve que o fizesse falar. A tourada se reuniu exigindo, entretanto o Tigre desapareceu sem dizer adeusinho, imitando as nuvens.

Gerenciar projetos é uma arte, que vem se desenvolvendo e evoluindo há tempos. Esta evolução, constante e esperada, faz parte do processo natural do desenvolvimento humano.

A gerência de projeto, como uma disciplina, foi desenvolvida de diversos campos de aplicação diferentes, incluindo a construção, a engenharia mecânica, projetos militares, etc.

O  conceito do desenvolvimento de tecnologia pode ser traçado desde o período Neolítico (~10.000 anos atrás), que marcou a transição da caça para agricultura e domesticação de animais. Com essa mudança, a evolução da engenharia, por assim dizer, acelerou, alcançando um primeiro pico durante o antigo reinado do Egito antigo (3.000 AC), com o desenvolvimento de sistemas de irrigação e esgoto, barcos, canais e claro, as inesquecíveis pirâmides. Em relação às pirâmides, é fato que consumiram  grande esforço humano e custo. Estima-se que cerca de 100.000 trabalhadores levaram 30 anos para completá-las, mas existem controvérsias sobre o número exato de trabalhadores e o tempo.

Projetos de grande porte também eram realizados em outras civilizações, como na Mesopotâmia, China e Grécia. Outros feitos de grandes proporções exemplificam a evolução os projetos com a Grande Muralha da China (220 AC), as campanhas militares de Alexandre o Grande, as realizações do Império Romano, o templo de Jerusalém.

Evolução

Henry Laurence Gantt, um engenheiro mecânico fez uma grande contribuição para a disciplina de gerenciamento de projetos em 1917 com a criação do famoso Gráfico de Gantt, um tipo de gráfico em barras que determina o cronograma do projeto. Essa ferramenta ainda é muito usada atualmente (MS Project).

Talvez o primeiro grande projeto que tenha aplicado o conceito de gerenciamento de projetos independente foi o Projeto Manhattan, que criou a primeira bomba atômica. Informações levantadas por historiadores indicam que o projeto estava em grandes dificuldades até que a liderança foi separada entre o gerenciamento do projeto (custo, prazo, escopo) liderado pelo general Leslie Groves, e o gerenciamento técnico, liderado pelo Dr. Robert Oppenheimer. Esta distinção foi um marco para o gerenciamento de projetos, pois até então era sempre o arquiteto ou especialista técnico que era responsável pelo gerenciamento de todos os elementos do projeto, o que muitas vezes provocava um conflito de interesses e causava grandes atrasos e gastos exagerados.

Reparou que não é de hoje a percepção de que nem sempre um excelente técnico pode ser um excelente gerente de projetos/gestor de projetos?

No entanto, o conceito do gerenciamento de projetos, como o conhecemos, teve suas origens no final dos anos 50, em decorrência da pressão do governo americano por uma corrida de desenvolvimento tecnológico durante a Guerra Fria.

O lançamento com sucesso do satélite Sputnik 1 pela União Soviética em 1957,  gerou uma reação forte dos americanos, que resultou em várias iniciativas do Departamento de Defesa (DoD), tais como:

• A corrida espacial, com a criação da NASA em 1958.
• Aumento drástico do fomento à pesquisa científica, aumentando em 1959 o orçamento da Fundação Nacional de Ciências americana de 34 para 134 milhões de dólares.
• Criação do Programa de Mísseis Polaris, com a construção de um submarino nuclear para diminuir a diferença em relação ao arsenal russo. O Almirante Raborn da marinha americana tinha urgência para realizar o programa e as ferramentas de gerenciamento de projetos tradicionais não eram suficientes para garantir a entrega do projeto. O DoD então desenvolveu com a ajuda de Willard Frazar o PERT (Program Evaluation and Review Technique), um sistema de sequenciamento de atividades que consegue determinar o menor tempo para a conclusão de um projeto. A utilização do PERT se tornou obrigatório para todos os projetos da marinha Americana.
• A Agência de Pesquisa Avançada de Projetos de Defesa do Pentágono iniciou nos anos 60 o projeto de uma rede de computadores chamada ARPANET, que foi a percussora da Internet de hoje.

Nesta mesma época outros avanços foram desenvolvidos no gerenciamento de projetos:

• A DuPont criou o CPM (Critical Path Method), ou Método do Caminho Crítico, que é amplamente usado para identificar quais são as atividades críticas que podem atrasar o projeto.
• O PERT foi depois estendido para o WBS (Work Breakdown Structure), também conhecido com Estrutura Analítica do Projeto.
• O método tradicional do Caminho Crítico se estendeu para a conhecida Cadeia Crítica, que é baseada na Teoria das Restrições, criada por Eliyahu M. Goldratt.

No período dos anos 60 a 90 houve uma grande demanda nos Estados Unidos  pelo desenvolvimento de grandes projetos tecnológicos estimulados pelo governo e poder militar.

A partir dos anos 90, com a abertura dos mercados internacionais ocorreu uma evolução acelerada da tecnologia e a comunicação tornou-se mais fácil. Certamente o surgimento e a proliferação da Internet aceleraram o processo, aumentando muito o ritmo de mudanças no ambiente.

O ambiente empresarial se tornou turbulento e mais caótico, demandando novos produtos, mais agilidade, inovação das empresas em busca de sobrevivência e destaque  num mercado cada vez mais disputado. Gerenciar bem projetos se tornou  estratégico para a sobrevivência das empresas.

Foram desenvolvidas muitas técnicas, consolidação de melhores práticas, ao longo dos anos que podem ser aplicadas no gerenciamento de projetos como  Project Management Body of Knowledge (PMBOK) do PMI, Personal Software Process (PSP), o Team Software Process (TSP) e PRINCE2.

Em relação a projetos de desenvolvimento de software, a partir da metade dos anos 90 surgem definições modernas de desenvolvimento de software ágil como parte de uma reação contra métodos “pesados”, caracterizados por uma forte regulamentação e micro gerenciamento, que buscavam planejar todos os detalhes antecipadamente.

Em 2001 foi publicado o Manifesto ágil, documento que reúne os princípios e práticas desta metodologia de desenvolvimento. Os métodos ágeis iniciais incluíram: Scrum (1986), Crystal Clear, Extreme Programming (XP) (1996), Adaptive Software Development, Feature Driven Development, and Dynamic Systems Development Method (1995).

Conclusão

Qual a melhor forma de gerenciar os projetos?  Creio que não exista uma receita de bolo pré-definida e que seja aplicável para todo e qualquer tipo de projeto.

As adaptações dos processos, métodos, metodologias às necessidades reais dos interessados, patrocinadores são bem vindas e talvez indiquem um dos caminhos a serem considerados na arte de gerenciar projetos.

Fontes

PETERS, Tom, WATERMAN, Robert H. In Search of Excellence, Warner Books Edition, 1982.

PORTER, Michael E. Estratégia Competitiva: Técnicas para Análise de Indústrias e da Concorrência. Rio de Janeiro: Campus, 1986.

CLELAND, David I. Project Management: Strategic Design and Implementation, 3^rd edition, New York: McGraw Hill International Editions, 1999.

KERZNER, Harold. Project Management: A systems Approach to Planning, Scheduling and Controlling. 7^th edition, New York: John Wiley & Sons, 2001.

RODES, Richard. The Making of the Atomic Bomb, New York: Touchstone Books, 1995.

THOMSETT, Rob. Managing large projects – a special case. The THOMSETT Company, 2000.

THOMSETT, Rob. Radical Project Management. New Jersey: Prentice Hall PTR, 2002.

Manifesto ágil, http://www.agilemanifesto.org/.

Vários profissionais questionam: Por que nossos projetos não acabam no prazo ou custo ou qualidade planejado(s) / desejado(s)?

Antes de questionarem isso, deveriam perguntar a si mesmos: O que fiz ou faço para que os projetos acabassem ou acabem no prazo ou custo ou qualidade planejado(s) / desejado(s)?

Esta última questão é muito importante, pois a análise detalhada desta resposta com certeza apresentará as lacunas que você ou que a organização possui ou pode possuir. Obs.: “Entenda como lacuna para este caso algo que não faça ou tenha, ou algo que possa ser melhorado.”

As atitudes e pensamentos dos gerentes de projetos e da organização devem andar em conjunto e no mesmo passo. A organização deve estar com seus projetos totalmente alinhados à estratégia organizacional ou conforme a uma necessidade de “força maior”. Um exemplo de necessidade de força maior é quando o presidente da empresa quer que o projeto XYZ seja executado mesmo que o projeto não esteja alinhado à estratégia organizacional. Este alinhamento entre a operação (execução dos projetos) e a estratégia (direção/norte da empresa) é muito importante, afinal, para que executar um projeto se o mesmo não vai atingir os objetivos necessários da organização? Considerando que na maior parte, os objetivos estratégicos são vitais para a continuidade e evolução da empresa.

Tudo isso está sendo dito, pelo simples motivo de que as práticas de Gerenciamento de Projetos são utilizadas para se executar os projetos da melhor forma possível a fim de aumentar substancialmente a probabilidade de sucesso dos projetos. Já as práticas de Gerenciamento de Portfólio de Projetos, em resumo, são para selecionar os projetos mais importantes para a empresa, avaliar e acompanhar os riscos e resultados quanto aos objetivos de negócio da organização. Ou seja, o ideal então é unirmos tais práticas: Gerenciamento de Portfólio de Projetos com Gerenciamento de Projetos, de modo que nós tenhamos ao final o seguinte resultado ->  “Fazer certo o projeto certo”.

Neste contexto, é aí que pode entrar o PMO (Project Management Office – Escritório de Projetos, ou nomenclatura que execute as funções e necessidades da organização. Lembrando, o PMO não possui um padrão, cada organização possui uma nomenclatura, funções, objetivos, entre outros aspectos para o seu PMO). O PMO, em relação as suas funções e amplitude, ele pode ser mais operacional, tático ou estratégico, de forma a ajudar a garantir o aumento da maturidade do gerenciamento de projetos nos respectivos profissionais e na organização como um todo.

Sendo o PMO mais operacional, ele pode:

• Definir os processos, artefatos e ferramentas para o gerenciamento de projetos na estrutura funcional na qual ele se encontra;
• Auditar os projetos a fim de ter a certeza de que os processos e práticas estabelecidas estão sendo seguidas;
• Ser um ponto focal e/ou de suporte para atendimento aos gerentes de projetos;
• Entre outras atividades…

Sendo o PMO mais estratégico, ele pode:

• Ajudar na priorização e seleção dos projetos da organização conforme banco de lições aprendidas e outras bases de conhecimentos;
• Ser o elo de comunicação entre o gerente de projetos e a alta direção;
• Realizar ou apoiar os Status Reports executivos / estratégicos;
• Apoiar o Gerente de Programas na gestão e acompanhamento dos projetos relacionados;
• Entre outras atividades…

Enfim, o PMO é o departamento no qual possui em “suas veias” informações, processos, profissionais capacitados e diretrizes específicas e fundamentais sobre os projetos e fazem com que os projetos possuam uma tendência de melhores resultados e consequentemente fazem com que a organização tenham os resultados esperados, conforme sua estratégia de negócio. Fazendo de si mesmo uma entidade/departamento/área de fundamental importância para a organização e o aumento da probabilidade de sucesso dos projetos e resultados de negócio da empresa.

Pense nisso: O PMO bem planejado e implementado, ao longo do tempo vira um centro de lucro para organização e não um centro de custos…

Ele incomodado, levantou com disposição, livre do cochilo, permitindo-se investigar o que estava a atormentar o seu colega, que nunca foi de gritar para ninguém.

- Calma gajo, o que aconteceu? –  Perguntou ele,  mas, ofegante, seu colega não conseguiu falar.

- Toma essa água, disse ele.

Foi então que regressaram as choraminhices, como se houvesse se deitado mais etanol na fogueira. Ele impaciente e arrependido por haver perdido um cochilo indagou:

- Diga lá pa, antes que derramo sobre vós um balde de água! – Naquele momento, o gato saiu correndo miando desesperadamente.  O Tigre intrigado foi informado que um Elefante malicioso descarregou no Gato miador, toda água de sua tromba. Porque atendia pausadamente, e sem disposição a solicitação do Elefante.

O Elefante, superintendente da floresta, se achou no direito de criticar o ritmo com que o Gato executava as suas atividades. O Tigre que era o chefe direto do Gato foi conversar com o Elefante, pois achava que ele não deveria ter ordenado o Gato.

- Chefe, quem manda lá só eu, não cabendo reclamação de sua parte.

O Elefante ouviu atentamente a reclamação e ficou tão triste e cabisbaixo que demitiu imediatamente o Tigre alegando que a queixa deveria ter sido apresentada pelo Leão, chefe imediato do Tigre.

Ele saiu, segurando sua  própria cauda, que parecia muito pesada, andava com dificuldade, quase errando os passos. Quando comunicou a equipe sobre o seu desligamento, ouviam-se vozes em coro de manifestação de descontentamento. Afinal ele era muito querido e sua liderança era exemplar, mesmo com os tiques de cochilo que o visitavam inesperadamente. Todos pediram demissão deixando o departamento como uma cabeçada desprovida de cabelo.

Essa atitude fez com que o Leão agisse bruscamente, colocou as mãos no rosto. “Quem ficar terá aumento salarial”, disse depois de pouco pensar, ação repetida por pescador que arremesse anzol na água para ver o que acontece. O apelo foi ignorado.

A avalanche atingiu outros departamentos que já apresentavam fisionomias de arrebentação. Todos os dias apareciam anúncios de oferecimento de oportunidade de emprego na terra do Elefante. A notícia chegou muito rapidamente aos ouvidos do Rinoceronte, concorrente imediato do Elefante, que não hesitou em apresentar uma proposta comercial para incorporar a floresta decadente.

Aliás, se estamos buscando transparência, a questão não é simplesmente comprovar o fato de o projeto estar em dia, mas também apresentar razões que implicam em seu atraso e, certamente, buscar ações de mitigação – mas isto é outra história.

Ah… o relatório de status – na verdade eu nunca tive muita simpatia por ele e, confesso, até hoje não encontrei quem realmente nutre com ele uma relação amigável.

Em alguns projetos, os relatórios de status parecem ter sido projetados por profissionais que são experts em Powerpoint, mas que não entendem nada de projetos, criando verdadeiras obras de arte, que se tornam impossíveis de manter atualizadas ao longo do ciclo de vida dos projetos: estrelas, losangos, linhas, cores, tabelas, e por aí vai. Pior, criam espaços minúsculos para texto, ficando impossível apresentar alguma informação relevante, tabelas com código de cores, relacionamentos impossíveis com riscos, datas previstas, ou datas realizadas. Finalmente, quando o gerente é capaz de escrever alguma coisa no espaço que restou, ou acaba sendo sintético demais, ou genérico demais, impedindo que seja comunicada a mensagem correta.

Além de fazer com que o gerente se torne mais preocupado com a forma, e muito pouco com o conteúdo, acaba sendo criada a cultura infeliz: a de que relatar a verdade é infinitamente menos relevante que criar um status agradável aos olhos.

Neste momento, talvez somente a experiência seja capaz de estabelecer um limite, afinal, quem deseja informações realmente detalhadas, deverá ser capaz de examinar o cronograma detalhado, planilhas de riscos e problemas, e os demais artefatos que deveriam fazer parte do dia a dia dos Gerentes de Projeto (GPs).

No cerne desta questão está o fato de que muitos Escritórios de Projetos (EPs) acabam se tornando indevidamente mais importantes que os GPs propriamente ditos, pois ao criarem demandas após demandas de relatórios adicionais, estatísticas e outras informações aleatórias, sobrecarregam os GPs que se tornam escravos destas atividades extraordinárias.

O fato é que o EP deveria ser capaz de coletar tais métricas das ferramentas que ele mesmo tenha definido para os projetos – qualquer coisa além disso, é pura invenção.

Finalmente, constantes alterações em metodologia, relatórios ad hoc cuja entrega seja “para ontem”, além de trazer um efeito perverso à moral geral dos profissionais, são claro sinal de que o nível de confiança dos executivos está baixo.

E isto, meu amigo, com certeza é mau sinal.

Nesta história, quem é do bem e quem é do mal?

Primeiramente, vamos entender que o PMO não é uma pessoa, mas sim um departamento ou área da empresa. Temos no PMO uma ou mais pessoas. A quantidade de pessoas em um PMO, sua estrutura e funções, dependem das necessidades da organização. Ou seja, não existe um padrão específico a ser seguido, pois “as dores” de cada organização variam conforme seu negócio, mercado, objetivos, etc.

A disciplina de gerenciamento de projetos exige que o profissional “Gerente de Projetos” atue e aplique suas competências (conhecimentos, habilidades e atitudes) nos aspectos operacionais do gerenciamento de projetos, de forma que o projeto tenha o máximo de probabilidade possível de sucesso sobre seus objetivos primários (custo, prazo, qualidade, etc) e secundários (satisfação do cliente, atendimento ao negócio, etc).

Assim, o gerente de projetos deve investir no sucesso do projeto conforme as melhores práticas de gerenciamento de projetos existentes no mercado e independente do conceito ou práticas utilizadas (PMI – Project Management Institute, IPMA – International Project Management Association, APM – Association of Project Managers, entre outros).

Em resumo, o gerente de projetos é o grande responsável pelo sucesso ou fracasso do projeto e é quem deve conduzir as atividades para que a equipe faça o que deve ser feito para a execução do projeto de forma motivadora, exercendo a liderança e o profissionalismo. Para isso ele deve usar seus Hard Skills (técnicas) e Soft Skills (assuntos humanos / comportamentais).

O PMO então possui um profissional responsável, que dependendo estrutura da organização pode se chamar “Gerente do PMO”, POM (Project Office Manager), ou outra nomenclatura compatível. Dependendo das necessidades, ele é o maior responsável pela:

• Definição da missão e visão do PMO;
• Avaliação do nível da maturidade e práticas do gerenciamento de projetos da organização / projeto(s);
• Definição do(s) tipo(s) do PMO(s), considerando que pode haver mais de um PMO dentro da organização ou projeto;
• Definição das funções e amplitudes do PMO;
• Aplicação e desenvolvimento da metodologia de gerenciamento de projetos;
• Disponibilização e execução do apoio e suporte aos projetos e aos gerentes de projetos;
• Realização de auditorias no projeto para garantir a execução dos processos, utilização dos artefatos / metodologia;
• Definição de indicadores e elaboração / apresentação de relatórios gerenciais ou executivos;
• Condução de projeto conforme necessidades da organização ou do projeto;
• Entre outras ações / funções estabelecidas ou necessárias pela organização.

Como podemos verificar, GPs e PMO, possuem características, papéis e aplicações bem diferentes, onde um pode complementar o outro. O PMO não possui um padrão específico, mas pode ser moldado conforme as necessidades da organização e principalmente com as necessidades dos GPs que atuam nos projetos. Não basta termos ótimos GPs ou ótimo(s) PMO(s), pois o ótimo precisa ser nos dois contextos, de forma que juntos eles alavanquem a maturidade de projetos da organização e dos profissionais envolvidos.

Afinal de contas, se os objetivos do projeto ou do PMO não forem cumpridos, todo o contexto do gerenciamento de projetos e maturidade da organização fica comprometido e sem credibilidade caso tenha muita recorrência desta falha.

Concluindo, os profissionais envolvidos são profissionais “do bem” que compartilham o objetivo comum “de sucesso dos projetos”, as atividades e assuntos relacionados. Não existem e não deve existir diferenças negativas entre os GPs e PMOs.

Eles são necessários e são os grandes responsáveis pela execução das estratégias, evolução e sobrevivência da organização. Pois atualmente estamos cada vez mais vivendo em um mundo “projetizado”, então, cada vez mais os profissionais e assuntos de projetos estarão juntos e próximos em uma união forte, decisiva e vital para o mundo dos negócios.