Dando continuidade a nossa série de artigos sobre governança de TI, iniciada com “introdução ao cobit e a governança de ti“, partimos agora para uma visão da estrutura geral do CobiT.

Introdução

Quem leu nosso primeiro artigo viu que o CobiT é um framework de melhores práticas generalista. Ele tenta abarcar todos os processos de TI essenciais para o funcionamento adequado da área. As principais funcionalidades do CobiT são:

• Alinhar a TI com o negócio.
• Implementar as melhores práticas da TI.
• Apoiar a TI a se adequar às imposições dos órgãos regulatórios.
• Estabelecer uma cultura de gestão baseada em processos.

Outros frameworks de melhores práticas tipo PMBok, ITIL, RUP, CMMi, SCRUM… tem uma abordagem técnica focada. RUP e PMBok, por exemplo, apresentam uma série de processos; já o CMMi traz uma lista de controles. No  CobiT, por outro lado, você vai encontrar uma organização mais complexa que passa por processos, controles, modelo de maturidade e mais; como se fosse o canivete suíço da TI. Então quem está acostumado com outras bibliotecas pode estranhar, mas com um pouco calma agente chega lá.

O mapa do CobiT são seus grandes temas: negócios, processos, controles e desempenho. Eles agrupam os elementos fundamentais da sua estrutura, estudando cada tema separadamente fica fácil consolidar uma visão no final. Vamos lá.

Negócios

O CobiT coloca o alinhamento entre a TI e o negócio por meio dos processos de TI como seu principal trabalho. Para guiar este alinhamento precisamos estabelecer os requisitos necessários para operação dos processos. Os requisitos começam a ser definidos pelos critérios de informação. São sete critérios básicos a serem observados pela TI durante todo o ciclo de vida da informação:

• Efetividade. Relevância e pertinência da informação para os processos de negócio e sua entrega em tempo e custos consistentes.
• Eficiência. Produção da informação com aproveitamento máximos dos recursos.
• Confidencialidade. Proteção da informação contra acesso não autorizado.
• Integridade. Completude e precisão da informação.
• Disponibilidade. Informação disponível para o processo de negócio quando for necessária.
• Conformidade. Adequação a leis, obrigações contratuais e normas.
• Confiabilidade. Tem a ver com passagem da informação correta para que gerência possa cumprir com suas responsabilidades.

itgi (adaptado) - cobit it and business goals

Os critérios atuam como requisitos de alto nível. Trazendo a questão para algo mais palpável, temos os objetivos da TI. Estes objetivos são definidos por uma cadeia de direcionadores que se inicia na formulação da estratégia da organização, por sua vez desdobrada em objetivos do negócio e estes, finalmente, em objetivos da TI. Os objetivos do negócio e da TI vão variar de organização para organização; entretanto, o CobiT provê uma lista genérica pata ambos, vejam na figura ao lado.

Processos

É por meio dos seus processos que o CobiT implementa os requisitos de funcionamento da TI. São 34 processos, agrupados em 4 categorias, chamadas de domínios. Os domínios são um tipo de PDCA e se apresentam como:

• Plan and Organise (PO). Direcionamento de alto nível para AI e DS.
• Acquire and Implement (AI). Desenvolvimento de soluções para disponibilização de novos serviços.
• Deliver and Support (DS). Provimento e sustentação dos serviços da TI.
• Monitor and Evaluate (ME). Monitoramento dos processos para garantir a implementação adequada do direcionamento.

De qualquer forma, os processos são elementos abstratos. Na visão do CobiT, o que faz os processos acontecerem de fato na organização — e assim viabilizar seus objetivos — são os recursos da TI:

• Aplicações. Sistemas de informação somados aos processos manuais de processamento da informação.
• Infra-estrutura. Servidores, roteadores, bancos de dados, sistemas operacionais, etc. O que faz as aplicações rodarem.
• Informação. É o dado processado pelas aplicações e utilizado pelo negócio.
• Pessoas. Independente se interno, terceirizado ou subcontratado, é todo o pessoal necessário para gerenciar e operar a TI.

Agora já começamos a entender melhor o CobiT, não? Os processos da TI são a parte básica do framework, fundamental para seu entendimento e implementação. A famosa figura do ITGI que abre este post mostra a ligação entre os conceitos discutidos até agora de critérios de informação e de recursos e processos da TI. Nos próximos artigos iremos explorar alguns processos do CobiT em mais detalhes.

Controles

Uma característica forte do CobiT é o controle do que acontece dentro da TI. O ITGI prega que o controle é a forma que a organização tem de garantir que os objetivos definidos estão sendo alcançados com o mínimo de desvios. Os controles complementam a definição por processos dando instrumentos para a gerência governar o funcionamento do modelo definido e atuar sobre os riscos e problemas. Sua presença na organização funciona como indicativo de bom funcionamento.

Os controles do CobiT estão distribuídos ao longo dos processos, vamos ter controles específicos de cada processo e, também, controles genéricos aplicáveis à todos os 34. Um exemplo de controle genérico é o “PC2 – Process Ownership” que determina que todo  processo deve ter um dono com suas responsabilidades claramente definidas; diferente de um controle específico para gerenciamento de projetos, como o “PO10.2 Project Management Framework” que fala da necessidade da organização ter um framework que defina o seu método para gerenciamento de projetos.

É bom destacar que para definir, implantar, executar e aprimorar todo esse mundo de controles a organização vai precisar dispor de tempo e dinheiro. Deve-se ter foco e pragmatismo na escolha dos controles que se quer colocar em prática. A decisão pauta-se sempre pelos objetivos prioritários da TI e do negócio.

Desempenho

O negócio dá a missão, os processos e controles os meios de alcança-la. O que falta mais? A visão de futuro. Toda organização precisa criar uma arquitetura que permita auto-avaliação e definição de rumos. Seja para evitar estragos de um funcionamento inadequado ou para determinar o curso de crescimento. Não estamos falando aqui do controle diário, este pedaço do CobiT fala da avaliação do próprio plano em prática.

itgi - generic maturity model

Para possibilitar o crescimento orientado da organização o CobiT define um modelo de maturidade em níveis, nos moldes do CMMi. Os níveis são (0) não existente, (1) ad hoc, (2) repetido, (3) definido, (4) gerenciado e (5) otimizado — a figura ao lado explica genericamente o significado de cada nível. Perceba que eles representam a capacidade real da organização conforme a prática dos seus processos e você vai encontrar na documentação explicações de como cada um dos 34 processos se comporta nos diferentes níveis de maturidade. Por exemplo, o processo “DS2 Manage Third-party Services” encontra-se no nível (3) Definido quando:

Well-documented procedures are in place to govern third-party services, with clear processes for vetting and negotiating with vendors. When an agreement for the provision of services is made, the relationship with the third party is purely a contractual one. The nature of the services to be provided is detailed in the contract and includes legal, operational and control requirements. The responsibility for oversight of third-party services is assigned. Contractual terms are based on standardised templates. The business risk associated with the third-party services is assessed and reported.

A sacada é trazer um mecanismo escalável, de fácil comunicação entre os diversos níveis da organização e passível de comparação contra a indústria. A questão de certificação, muita vezes colocada em primeiro plano pelas organizações é secundária. A necessidade real da maioria da empresas é o de instrumentar um roadmap de evolução com algo mais mais do que o felling dos gestores.

itgi - cobit goals relationship

Numa linha mais operacional, mas ainda ligada a questão de performance vale destacar que o CobiT projeta um modelo genérico para acompanhar o desempenho dos processos. Ele é baseado na visão de objetivos de TI discutidos na primeira seção do artigo. Há o entendimento que o direcionador de alto nível para a TI são os objetivos do negócio que, por sua vez, definem os objetivos da TI. Os objetivos da TI são implementados por meio de processos e as atividades destes. Seguindo essa lógica, os objetivos da TI podem ser desdobrados em objetivos de processos e estes, em objetivos de atividades. A figura ao lado ilustra o raciocínio.

itgi (modificado) - cobit goals and metrics

Para acompanhar o atingimento de cada destes objetivos (negócios, ti, processos e atividades) temos as métricas de resultados (KGI ou outcome measures) e métricas de performance (KPI ou performance indicators). A métrica de resultado determina se um objetivo foi ou não alcançado e só pode ser medida ao final do processo, já a métrica de performance avisa se o objetivo vai ou não ser atingindo ainda há tempo de se tomar ações preventivas ou corretivas. A métrica de performance de um objetivo de negócio vira métrica de resultado para seu objetivos de TI; e assim por diante como vemos na figura ao lado. As métricas sugeridas pelo CobiT são apresentada em uma seção específica dentro de cada processo.

Conclusão

Vimos os elementos essenciais da arquitetura do CobiT estão baseados nos conceitos de negócios, processos, controles e desempenho. Os critérios de informação e objetivos do negócio e da ti dão o norte. Aplicando os recursos da TI sobre os processos conseguimos alcançar os objetivos da área. Por meio de controles e métricas garantimos a correta execução dos processos. Por último, temos um modelo de maturidade que colhe feedback do funcionamento, permitindo à organização se auto-aprimorar. No próximo artigo veremos como estes conceitos se aplicam em alguns dos processos do CobiT.

Posts Relacionados:

1. introdução ao cobit e a governança de ti primeiro da série de artigos sobre cobit e governança de...

Apesar da Governança de TI ser um tema de responsabilidade da alta liderança da organização, são normalmente os profissionais da TI que constroem a ponte entre a visão executiva e a proposta de solução. Este artigo é o primeiro de uma série sobre os fundamentos do CobiT. Nossa proposta é promover uma visão introdutória deste framework e facilitar um posterior mergulho no tema para o público do Tabuleiro de Projetos.

Os desafios da TI

Todo executivo sabe do valor da informação como um diferencial competitivo para o seu negócio. Gradativamente a TI vai migrando das diretorias de logística e administração para uma caixinha ligada diretamente ao CEO, mais investimentos são colocados a disposição de projetos de TI e, cada vez mais, os processos centrais do negócio tornam-se fortemente dependentes de software e hardware. Esse movimento aumenta a pressão por resultados. A área precisa abandonar o perfil caixa-preta e mostrar garantias de retorno para esse movimento estratégico.

A Governança de TI se apresenta como um sistema organizacional com processos e estruturas responsáveis por garantir que a TI está trabalhando alinhada com o negócio, maximizando resultados e otimizando a aplicação de recursos. Para o ITGI^1., a govervança de TI está centrada na geração de valor, gerenciamento dos riscos e controle da informação, vindo atender a necessidade das organizações satisfazerem as exigências de qualidade, fiduciárias e de segurança da informação.

Os frameworks de melhores práticas e o CobiT

Em buscas de resposta rápida aos pedidos dos nossos patrocinadores, recorremos aos padrões e bibliotecas de conhecimento, por assim dizer, “da moda”. PMBok, ITIL, CobiT, ISO 17799, CMMI e outros, viraram tábuas de salvação para muitos profissionais. O gerente de TI deve ter o cuidado de consolidar um profundo conhecimento sobre os desafios essenciais da sua organização e ecossistema (clientes, indústria, fornecedores…) e desenvolver habilidades analíticas e de liderança capazes de viabilizar a ponte entre as necessidades e recursos à disposição. Daí sim, a partir destes pilares, extrair valor de frameworks de melhores práticas, consensuados, escritos e validados por profissionais e instituições de renome e sucesso comprovados com certeza é uma mão na roda.

O Control Objectives for Information and related Tecnology (CobiT) tem se apresentado como um guarda-chuva para as melhores práticas da TI. Um modelo do que deve ser implementado e medido na TI para fazê-la atender as expectativas das organização. De quebra, servindo também como uma bússola para identificação de quais são os demais frameworks necessários para se aprofundar nos processo críticos.

O CobiT foca principalmente no alinhamento entre a TI e o negócio, na entrega de valor, no gerenciamento de recursos, no gerenciamento de riscos e na medição de performance — a figura do ITGI que abre este artigo é uma imagem tarimbada das áreas de foco do CobiT. Estas áreas são os tópicos principais que devem preocupar os executivos de TI, o CobiT tenta viabilizar estes resultados determinando um conjunto de 34 processos críticos a serem executados pela TI e uma infra-estrutura com guias e controles para implantação e aprimoramento da aplicação destes processos.

O CobiT propõe o que deve ser feito ao determinar quais processos devem ser executados e como medir sua efetividade. Diz, por exemplo, que a empresa deve executar o processo “Manage Projects” e medir sua eficácia com a métrica “Percent of projects meeting stakeholders expectations (on time, on budget and meeting requirements—weighted by importance)”. Entretanto, não diz como fazer. Para descobrir como gerenciar projetos a empresa vai ter procurar em framework como PMBok e PRINCE2. Para ajudar nesse link o ITGI disponibiliza uma série de documentos de mapeamento como o Mapping of PMBOK With COBIT 4.0.

itgi: produtos do cobit

Todo este conhecimento é trabalhado numa série de produtos voltados para executivos, gerentes e especialistas de governança. A pirâmide ao lado organiza os principais documentos que contituem a base do CobiT: Board Briefing on IT Governance; Management guidelines/maturity models; Frameworks; Control objectives; IT Governance Implementation Guide: Using COBIT and Val IT; COBIT Control Practices: Guidance to Achieve Control Objectives for Successful IT Governance e IT Assurance Guide: Using COBIT. Boa parte desse material, além de uma série artigos e livros complementares são gratuitos e contrados no site da ISACA.

Nos próximos artigos vamos dar mais detalhes do funcionamento geral do CobiT.

1. ITGI. CobiT v4.1

Posts Relacionados:

1. arquitetura e organização do cobit o segundo artigo da série sobre governança de ti oferece...

Sempre que via o noticiário financeiro admirava aqueles caras trabalhando com um monte de monitores. Um dia descobri que tanto Windows quanto Linux administram isso com tranqüilidade, basta plugar o monitor e realizar alguma configuração básica. Testei. Desde então sou um entusiasta. O pessoal do trabalho estranha um pouco e minha esposa no começo ficou meio atrapalhada, mas quem topa experimentar sempre se converte.

Ao ler esta pesquisa da Microsoft (vi aqui no Digital Inspiration) descobri que a ciência está ao meu lado. Olhem só.

Microsoft researchers haven’t perfected the genie, but they’ve found a tool that can increase your productivity by 9 to 50 percent and make your work day easier. And you can begin using it right away.

Ou seja, o pessoal lá viu que a sua produtividade pode aumentar em até 50%. Vejam mais.

Give someone a second monitor, let them use it for while, and then try to take it away. It just isn’t going to happen. They’ll never go back to a mono display. Researchers in the Visualization and Interaction for Business and Entertainment group (VIBE), found that increasing a computer user’s display space made it easier for them to complete their tasks.

As celebridades também aderem. Bill Gate, nesta entrevista para o blog Life Hacker, fala como usa seus três monitores na rotina diária.

I keep my Outlook 2007 Inbox open on the screen to the left so I can see new messages as they come in. I usually have the message or document that I’m currently reading or writing in the center screen. The screen on the right is where I have room to open up a browser or look at a document that someone has sent me in e-mail.

Os notebooks são os computadores mais fáceis pra começar a brincar. Todos vem com aquela saída lateral normalmente usada em datashows para apresentações. Você prepara um ambiente para seu notebook ficar ao lado do monitor principal (vejam a imagem do inicio do artigo), pluga o monitor naquela saída que mencionei e configura o esquema de telas. No Windows XP, por exemplo, basta clicar com o botão direito na área de trabalho, acessar “propriedades” e deixar a aba configurações conforme tela ao lado.

Esse esquema é interessante porque te dá a mobilidade do notebook e o conforto do desktop em apenas uma máquina. Mas várias opções estão disponíveis, tem pessoas que montam grandes painéis com 3, 4 e até 9 monitores ligados em potentes placas de video dos seus desktops. Façam o teste. Vicio garantido.

Ano passado eu e o Iran Porto tivemos um artigo sobre o case de implantação de GP aqui do SERPRO selecionado para apresentação no 3° Congresso Brasileiro de GP . Hoje divido com vocês uma versão resumida e com algumas atualizações deste trabalho que pode ajudar quem está envolvido com a implantação do gerenciamento de projetos e portfólio em suas organizações.

Veja aqui informações sobre o 4° Congresso Brasileiro de GP que acontecerá em novembro de 2009 em Belo Horizonte .

1. Introdução

O gerenciamento de projetos tem sido reconhecido como fator primordial para as empresas que buscam uma vantagem competitiva, em especial por balancear as expectativas dos interessados aos recursos disponíveis, garantindo o atendimento das suas necessidades e o desempenho empresarial.

Por um longo tempo, os projetos foram administrados por gerentes de projeto designados pela experiência técnica bem sucedida num determinado assunto. Porém, o índice de falhas em projetos levou a uma mudança progressiva na forma de gerenciá-los, sendo o moderno gerenciamento de projetos preocupado com métodos e técnicas que sejam aplicáveis a projetos de diferente porte e complexidade, com um enfoque fortemente gerencial e não meramente técnico. Planejamento, acompanhamento e execução dos projetos, de forma consistente e lógica, passaram a ser vistos como uma forma de aumentar o índice de sucesso de projetos.^1.

Assim como a prática de gerenciamento de projetos tem crescido, há também uma demanda significativa por um método sistemático de implantação de procedimentos, técnicas e ferramentas de gestão de projetos em nível corporativo. Entre as muitas estruturas de gerenciamento de projetos utilizadas, provavelmente a de maior sucesso é o Escritório de Projetos.

2. Motivação

O Serviço Federal de Processamento de Dados – SERPRO é uma empresa pública, vinculada ao Ministério da Fazenda. Foi criada em 1964 com o objetivo de modernizar e dar agilidade a setores estratégicos da Administração Pública brasileira. A Empresa, cujo negócio é a prestação de serviços em Tecnologia da Informação e Comunicações para o setor público, é considerada uma das maiores organizações do setor na América Latina.

Com a constante modernização dos processos de desenvolvimento de soluções de TI e aumento na complexidade das necessidades da administração pública. Determinadas questões percebem-se críticas na condução da organização, principalmente:

• Falta de informações para monitoramento do portfólio de projetos.
• Projetos desenvolvidos de forma isolada.
• Redução do desvio de qualidade, incertezas e riscos, diminuindo os custos do projeto.
• Clareza de papéis e responsabilidades.
• Alinhamento das ações à estratégia da empresa.
• Priorização do trabalho, com base em informações disponibilizadas para todos os interessados.
• Foco no gerenciamento de projetos que requerem maior intervenção e são mais importantes para a organização.
• Informação obtida e disseminada entre os projetos e unidades, ajudando na comunicação.
• Lições aprendidas documentadas, facilidade de transmissão de conhecimento e da comunicação.
• Ferramentas e técnicas de gerenciamento de projetos são compartilhadas entre todos os envolvidos.

3. Implantação

3. 1 Estratégia da Implantação

Como condutores da implantação e aplicação dos conceitos do gerenciamento de projetos foram definidos os Escritórios de Projetos com atribuições de nível Estratégico e de Suporte e Controle. O Escritório Estratégico de Projetos fica voltado principalmente para estabelecimento e melhoria contínua dos direcionamentos estratégicos, monitoramento do desempenho dos projetos e provisão de informações à Diretoria, atuando por meio de grupos interáreas envolvendo profissionais de toda Empresa.

Visão de Gerenciamento de Projetos na Organização

O Escritório de Suporte e Controle de Projeto instituído no âmbito de cada Superintendência desempenha papéis voltados principalmente para o desenvolvimento e suporte dos Gestores de Projetos e controle do desempenho dos projetos geridos naquela unidade.

Também foi criado o papel de Gestor de Projeto com a função de gerenciar e conduzir um projeto, o que inclui, liderança, planejamento e gestão do desenvolvimento de todos os resultados entregáveis do projeto.

Com o objetivo de identificar as ações necessárias, foi considerado o contexto do gerenciamento de projetos adotados em nível corporativo, onde várias questões foram observadas de forma integrada, vide figura ao lado, e o encadeamento das ações foi uma premissa para garantir o sucesso da iniciativa.

O resultado desta análise foi a decomposição da implantação em fases administráveis, baseadas em ações graduais de amadurecimento e internalização dos conceitos, técnicas e práticas mais adequadas ao SERPRO, com entrega de produtos bem definidos e com o envolvimento de todas as unidades desde o início, em trabalhos conduzidos por equipes multifuncionais. A implantação em fases permitiu a realização de mudanças culturais necessárias e de forma gradativa.

3.2 Fases da Implantação

As fases foram organizadas considerando, também, os três pilares fundamentais em qualquer estratégia: processos, pessoas e tecnologia.

Neste sentido, a primeira fase estava focada no amadurecimento do conhecimento e criação dos fundamentos básicos de Gerenciamento de Projetos na Empresa, o que se traduziu na elaboração de uma Política Corporativa, de um Processo de Gerenciamento de Projetos e de um Programa Corporativo de Implantação do gerenciamento de projetos no Serpro. Realização de benchmarking, disseminação (palestras, aquisição de livros especializados no assunto e criação da comunidade de Gestão de Projetos no SERPRO) e conhecimento do uso atual de práticas de gerenciamento de projetos nas unidades do SERPRO ocorreram nesta fase inicial, em paralelo à capacitação em Gerência de Projetos, baseada nas práticas do PMI – Project Management Institute, com o objetivo de nivelar o grau de conhecimento e conceitos dos representantes das Unidades.

A segunda fase constituiu-se da instituição da política e do processo corporativo de gerenciamento de projetos e focava em ações de conscientização e realização de projetos pilotos, inclusive para criação do Portfólio de Projetos. Em paralelo, ações de planejamento, de contratação de treinamentos e de especificação de ferramenta para apoio ao gerenciamento de projetos foram planejadas. Foi uma fase de curta duração, cujos resultados foram úteis para capacitação e iniciativas de implantação de gerenciamento de projetos nas Unidades na fase posterior. Foram previstas ações para divulgação maciça, instituição do Comitê Gestor, com representantes das Unidades e do Escritório Estratégico de Projetos, absorção pelas Unidades das atribuições relativas aos Escritórios de Suporte e Controle de Projetos, aplicação do processo corporativo em pequenas iniciativas das Unidades envolvendo os profissionais que foram treinados e criação de um guia para orientar o planejamento de implantação pelas Unidades na próxima fase.

Na terceira fase, o foco estava na implantação efetiva do processo nas unidades, sob coordenação do Escritório de Suporte e Controle de Projetos da Unidade e acompanhamento pelo Escritório Estratégico de Projetos. Um Plano de ações foi elaborado por cada Superintendência, com base no guia elaborado na segunda fase, prevendo treinamentos seguidos de aplicação em projetos reais não críticos e de curto prazo, servindo como marco efetivo da implantação da cultura na Unidade. Foi uma fase com maior tempo de duração, pois previa também o desenvolvimento ou a aquisição de ferramenta para apoio ao gerenciamento de projetos, que dependia de processo de licitação, promoção de oficinas de trabalho para aplicação de técnicas adotadas no processo corporativo e incentivo a certificação PMP – Project Management Professional.

Na quarta fase, o Escritório de Suporte e Controle de Projetos das Unidades, assessorado pelo Escritório Estratégico de projetos, deveria dar ênfase à extensão da implantação do processo corporativo a projetos de toda natureza realizados pela Unidade, ao uso das lições aprendidas e à certificação PMP de seus profissionais. Todos os projetos deveriam ser contemplados no Portfólio, o aculturamento em gerenciamento de projetos deveria ser provido a toda a Empresa, por meio de curso E@D e o esforço e os resultados deveriam ser objeto de avaliações do processo corporativo em busca de melhoria e da viabilidade de integração com as demais ferramentas existentes no Serpro.

Na quinta fase, o foco era na transição para a melhoria contínua, onde as ações deveriam ser direcionadas para a melhoria dos processos, atualização de software e meios de comunicação, reciclagem da equipe e avaliação da maturidade da Empresa em gerenciamento de projetos, para planejamento de ações posteriores.

4. Benefícios Alcançados

Ao final de cada fase foram realizadas avaliações quanto ao cumprimento dos objetivos propostos por cada unidade da empresa, sendo possível, já nestes momentos, identificar uma série de benefícios alcançados, tais como:

• Aumento significativo da cultura organizacional relacionada ao tema gerenciamento de projetos;
• Melhoria na qualidade da gestão dos projetos conduzidos pela organização, com impacto positivo percebido, inclusive, pelo cliente, que começa a requisitar pró-ativamente os artefatos e atividades previstas no Processo de Gerenciamento de Projetos do Serpro (PGPS);
• Interesse crescente pela busca de certificação em gerenciamento de projetos pelo corpo funcional da organização. O SERPRO saltou de 4 empregados certificados PMP em 2004 para mais de 100 empregados certificados em 2008;

5. Melhoria Contínua

Durante o primeiro semestre de 2008, enquanto encerrava-se a 4° fase, realizou-se a transição do projeto de implantação para o momento de melhoria contínua. A definição da estratégia de evolução deu-se essencialmente através de discussões entre Escritório Estratégico de Projetos e a alta liderança da empresa. Como produto das discussões foi criado o Sistema de Gerenciamento de Projetos do Serpro (SGPS) compreendendo todo o conjunto de componentes responsáveis pela execução e evolução da solução de gerenciamento de projetos da empresa, como, por exemplo, estruturas funcionais, cursos, processos, ferramentas, etc.

Também foram criados o Processo de Estruturação do SGPS, que agrega todas as ações de evolução do SGPS, e o Grupo de Trabalho de Estruturação do SGPS (GT-SGPS), grupo inter-área de funcionários que assumiu a responsabilidade por conduzir as atividades do processo. Tanto o processo quanto o GT-SGPS são coordenados pelo Escritório Estratégico de Projetos.

O Processo define um canal para controlar o ciclo de vida das demandas de melhorias por meio do sistema corporativo para gestão de demandas da empresa (Sistema Demandas). O conjunto de demandas ativas em um determinado momento fica denominado “Balde”. Os Escritórios de Projetos departamentais centralizam a abertura de demandas colhidas em suas áreas e o Escritório Estratégico de Projetos abre demandas em seu próprio nome e sob comando da Diretoria.

Passa a acontecer planejamento anual do processo, onde, baseando-se no planejamento estratégico da empresa e em orientações táticas da Diretoria, são selecionadas quais demandas do Balde serão implementadas pelo GT-SGPS até o final do exercício. Os escopos de demandas afins são agrupados em subprojetos e estes, por sua vez, ficam subordinados a um projeto maior que responde pelo escopo total para aquele ano. Este projeto é gerido pelo coordenador do GT-SGPS e seus subprojetos, geridos e executados pelos demais membros do grupo de trabalho.

Continuamente a coordenação do grupo monitora mudanças no Balde, na situação do projeto e subprojetos e na estratégia da instituição, de forma a manter o alinhamento com o cenário empresarial.

A título de ilustração, descrevemos as principais demandas selecionadas para tratamento:

• consolidar acompanhamento objetivo dos projetos baseando-se em indicadores e paineis de controle específicos para os diversos níveis de comando da empresa;
• aumentar a velocidade e transparência na (re)priorização dos projetos;
• atualizar o SGPS para suportar à gestão de programas;
• definir roteiro ágil de uso do PGPS e funções que permitam e auxiliem a adaptação do processo às realidades especificas dos projetos;
• transferir as informações de gestão, dos documentos eletrônicos, para o sistema de gestão de portfólio;
• implantar o software livre de gerenciamento centralizado de cronograma e eap;
• expandir a estrutura de representantes de escritório de projetos até as regionais da empresa;
• revisar estratégia de capacitação de pessoas de forma a otimizar os resultados do incentivo à certificação PMP e implantar treinamentos avançados em práticas críticas como construção de EAP e cronogramas.

6. Gestão de Portfólio

A solução de gestão de portfólio do SERPRO foca na priorização e no acompanhamento e controle da situação dos projetos. A definição e implantação da metodologia iniciou  pelo monitoramento do portfólio visando o tratamento antecipado das ocorrência de riscos. A estrutura básica da solução baseia-se na execução de ciclos de gestão, utilizando o software e-Car como portal de informações dos projetos e instrumentador dos ciclos.

O e-Car é uma ferramenta livre para acompanhamento e controle de resultados empresariais, foi originalmente desenvolvida pela Companhia de Informática do Paraná (CELEPAR) e hoje é gerida por uma comunidade de usuários. Além do SERPRO, várias organizações utilizam e participam da manutenção do e-Car como o Governo do Estado do Paraná, a Subchefia de Assuntos Federativos da Presidência da República, o Estado da Bahia e o Governo do Estado do Pará.

Após a execução de cada ciclo o Escritório de Projetos consolida as informações em um relatório executivo com os pontos críticos que serão levados disponíveis para uso pela Diretoria e Assessores que podem utiliza-lo como instrumento na tomada de decisão.

Atualmente o esforço concentra-se na implantação das atividades de alinhamento de portfólio que têm foco na priorização e coordenação da alocação de recursos em projetos.

7. Conclusões

A partir do processo de implantação e dos objetivos traçados para os próximos ciclos de evolução e massificação do gerenciamento de projetos na organização, fica claro a dimensão de valor que a disciplina passa a ocupar na administração da empresa, tomando papel fundamental na priorização e acompanhamento das ações estratégicas e aumento da produtividade.

Também percebemos que o processo de implantação não é trivial, envolve grandes desafios, especialmente no trato dos fatores comportamentais do corpo funcional. Determinante para o sucesso é a estratégia de entregas progressivas em curtos intervalos de tempo, de forma a demonstrar os benefícios da metodologia o mais cedo possível e, também, sua constante potencialidade de expansão.

1. KERZNER, Harold. (1996). “The Growth and Maturity of Modern Project Management”, Project Management Institute, 27th Annual Seminar, Boston, Massachusetts.

Posts Relacionados:

1. Estudo do Gerenciamento de Projetos Nacional Apoio para os envolvidos na difícil tarefa de implantar e...
2. 5 arquiteturas organizacionais Introdução à disciplina da Arquitetura Organizacional por meio da análise...
3. Bom Material: Improving Maturity within Organizations Muita coisa interessante aconteceu no evento Improving Maturity within Organizations....

Alguns posts atrás publicamos uma imagem que serve como sistema de decisão para escolher o gráfico para melhor representar seus dados — depois que eu descobri esse negócio não paro mais de usar. Recentemente tomei contato com o Chart Chooser que faz basicamente a mesma coisa mas com uma interface web mais aprimorada, além de ofertar templates para powerpoint e excel. Os dois métodos tem algumas sugestões diferentes, mas basicamente são muito próximos. Recomendo olhar os dois e escolher o que mais lhe apeteça.

Posts Relacionados:

1. ai meu deus, qual gráfico escolho? O diagrama oferece um sistema de decisão que ajuda a...

Vai até o dia 10/8 o limite para a entrega de trabalhos para o 4° Congresso Brasileiro de Gerenciamento de Projetos. Todas as regras para submissão de artigos encontram-se aqui. O evento irá acontecer em Belo Horizonte entre os dias 11 e 13 de novembro.

O congresso é promovido pelos capítulos PMI nacionais e desde o ano passado se consolidou como o principal da área  no Brasil, posição reforçada quando o PMI decidiu não promover mais seu congresso internacional da América Latina e passar a investir em eventos locais.

Posts Relacionados:

1. 3º Congresso Brasileiro de GP Nos dias 22, 23 e 24 de outubro de 2008,...
2. Dicas Quentes 3° Congresso Brasileiro de GP De 22 à 24 de outubro, em Porto Alegre, vai...
3. Estudo do Gerenciamento de Projetos Nacional Apoio para os envolvidos na difícil tarefa de implantar e...

O autor deste artigo de 2 páginas é pai da frase “você não pode controlar o que não pode medir”. Ele dá um depoimento de como mudou sua visão sobre os projetos de sofware e a própria disciplina de engenharia de sofware. Já admiro de graça um homem que publicamente assume uma mudança de posição deste jeito, sem justificativas e de forma tão aberta. Mas o mais importante do artigo é a construção da constatação de que não dá mais pra encarar o fazer software como um trabalho de engenharia.

Vi no blog do José Papo.

Posts Relacionados:

1. CIO: 7 maneiras de melhorar o lançamento de software Artigo da CIO oferece dicas para aprimorar o processo de...

Sempre escutei que metodologias ágeis — na época essa palavra era a mesma coisa que dizer XP — serviam para pequenos projetos onde todos estivem no mesmo ambiente físico. Dois excelentes artigos da SearchSoftwareQuality deram uma sacudida no paradigma de pequenos projetos.

A grande frase do Scott Amber no artigo é que problemas com grandes times não é da metodologia ágil mas da própria natureza de ter várias pessoas trabalhando no mesmo projeto: ‘How does software development scale in general?’ Traditional development doesn’t scale very well anyway; you hear all the time of large projects that were cancelled or delayed. Scaling is independent of methodology”.

Sendo assim, a dúvida é qual dos métodos é o mais adequado para lidar com times de grande escala. O autor do artigo, Colleen Frye, questiona Damon Poole sobre o tema. O fundador e CTO da AccuRev Incc diz acreditar na solução ágil como a melhor, mas deixa uma dúvida no ar.

Does Poole believe agile scales better than traditional methodology? “Absolutely.” However, he added, “There’s a question of proven scalability. There are fewer proof points of agile scalability; that’s just the way it is because there are fewer large projects. But look at the algorithm of agile development. There’s more in it that allows you to scale.”

De qualquer forma, a dica principal para trabalhar com muita gente utilizando agile é componentizar o trabalho, criando sub-times. Aplicamos as técnicas ágeis tradicionais em cada time, adotando instrumentos específicos para integrar engenharia e gestão ao nível global do projeto. Vejam:

At IBM, Ambler said there are other agile projects on the order of 500 to 600 people. To manage large teams, both Ambler and Poole agree the project needs to be broken down into smaller components and sub-teams. “There’s no magic to this,” Ambler said. “The architecture should be a system of subsystems.”

A visão de grandes projetos de software como problemáticos por natureza considero uma verdade, confesso que o me incomoda é a aceitação que times virtuais são uma má idéia e pronto. Naturalmente é melhor ter todos na mesma sala, mas muitas vezes este cenário não é controlado, a distribuição geográfica é uma restrição do projeto. Estou na torcida por uma proposta matadora para o desenvolvimento ágil com times distribuídos, quem sabe alguém aí tem uma sugestão.

Leiam os artigos em Agile development: It isn’t just for small projects e Suggestions for scaling agile.

Bom fim-de-semana à todos.

Posts Relacionados:

1. Maré de Agilidade No tabuleiro do Maré tem… Scrum, Olodum XP, TDD, FDD,...

Meu amigo Luciano me mandou esse artigo do Anthony Berglas. Nele o Dr. Berglas diz que a melhor coisa a fazer é agradecer aos gerentes de projeto de TI quando seus projetos falham. Afinal, toda vez que eles dão certo e agilizam alguma coisa a burocracia simplesmente se torna mais complexa e rouba todo o ganho de produtividade. O artigo é curto e muito bem redigido, vale a pena. Vejam o resumo.

This paper boldly challenges the long established misconception that the catastrophic failure of expensive software projects is detrimental to society.  Historical analysis shows that massive software automation has not increased the real efficiency of bureaucracies such as the Australian Tax Office since the 1950s.  Any increase in the efficiency of individual workers has simply been consumed by increased bureaucratic complexity, as predicted by Parkinson’s law.   As the primary net effect of software is to facilitate bureaucratic complexity it is therefor essential that software projects fail if society is to function effectively.  In this way the heavy burden of guilt can be lifted from the shoulders of the numerous project managers that have subconsciously devoted their careers to ensuring that projects rarely, if ever, succeed.

Posts Relacionados:

1. mais sobre projetos e programas Mais uma visão sobre a diferença entre programas e projetos...

Já estava há tempos com vontade de divulgar este artigo do pmtips.  O Brad Egeland propõe uma estrutura de relatório semanal simples e prático. Quem quiser pode ver o artigo completo aqui.

Sumário

Ele sugere começar o relatório com um sumário do projeto com informações gerais e destaques.

a summary section which outlines the project title, sponsor, delivery team leadership, and key dates.

Contatos

Daí vem uma seção com os principais contatos do projeto.

should include names, email addresses and phone numbers for all project team members for both the customer and the delivery organization. It serves as the source for contact information throughout the project

Neste caso especifico eu prefiro manter as informações de contato no wiki do projeto. Você sabe que a informação em mãos é a mais atual e abre a possibilidade das próprias pessoas manterem seus dados.

Dashboard

Um ou mais indicadores chave de interesse do cliente ou patrocinador.

I utilize the standard Green (On Target), Yellow (Concern), Red (Off Schedule or Off Budget). Other key indicators can be included such as customer satisfaction or individual schedule milestones that deserve close attention.

Duas informações que costumo praticar são Cumprimento de Prazo — (percentual realizado do cronograma *100) / percentual planejado do cronograma — e Conclusividade — percentual realizado do cronograma.

Cronograma

Uma lista com as atividades completadas no período, atividades planejadas para iniciar ou completar no período e aquelas atividades atrasadas em inicio ou conclusão no período.

A dica é usar os filtros da ferramenta de cronograma para obter rapidamente estas informações.

Problemas e Riscos

Uma lista dos problemas e riscos do projeto. Pode aparecer no corpo do documento ou ser encaminhada em uma planilha anexo.

I usually keep them as a separate spreadsheet with a tab for issues and a tab for risks and deliver them with the weekly Status Report to the team and the customer. However, I have incorporated them into the actual Status Report – it probably depends more on how lengthy they than anything else. We want to keep the Status Report as uncluttered and readable as possible.

Eu, particularmente, trato tudo que é problema do projeto, seja ocorrido ou à acontecer, como risco. O básico é mostrar um título, causas, conseqüências e ações corretivas e preventivas. Sempre falo nas conseqüências em termos de algum marco de entrega do projeto e nas ações costumo colocar data de conclusão, responsável e situação (proposta, em andamento, concluída…)

O segredo é manter o documento objetivo. Detalhes sempre vão ser esclarecidos verbalmente. Foque nas coisas mais importantes fique entre 1 e 3 páginas, no máximo.