PMBOK – Introdução (Parte 2)

Como já dissemos na publicação anterior, projetos são frequentemente utilizados como meio de realizar o plano estratégico de uma organização. Normalmente são motivados pelos seguintes fatores:

1 – Demandas de Mercado.
2 – Necessidades organizacionais.
3 – Solicitações de clientes.
4 – Avanços tecnológicos.
5 – Requisitos legais.

Diante desses motivos, o gerenciamento de projetos, como tá dando para notar, existe dentro de um contexto mais amplo que engloba também o gerenciamento de portfólios, o gerenciamento de programas, a existência de um escritório de projetos (PMO - Project Managment office) e a própria estrutura organizacional onde o projeto será realizado.

Nesta postagem estaremos falando da relação entre portfólio, programas, projetos e subprojetos.

Como mostra a figura acima, entende-se como portfólio, o conjunto de projetos, programas e outros trabalhos agrupados para facilitar o seu gerenciamento a fim de atender aos objetivos estratégicos de negócio. Os projetos e programas do portfólio podem ser independentes entre si ou se relacionarem de forma indireta. Devemos ter em mente que o portfólio é definido sempre olhando para cima, ou seja, para o planejamento estratégico, já os programas, olham para baixo, para interdependência dos projetos que os compõem.

Já que tocamos no assunto no parágrafo anterior, programas podem ser definidos como um grupo de projetos obrigatoriamente relacionados que são gerenciados de forma coordenada para a obtenção de resultados e controles que não seriam possíveis se fossem gerenciados individualmente. Nos programas podem existir elementos de trabalho fora do escopo dos projetos que os compõem, assim como podem envolver uma série de empreendimentos repetitivos ou cíclicos. É importante lembrar que cada projeto que compõe um programa tem um ciclo de vida próprio, tem autonomia e objetivos claros e entrega um produto ou serviço ao seu final.

Por fim, subprojetos são divisões de projetos, normalmente grandes, e não possuem vida própria, ou seja, só fazem sentido se estiverem dentro do contexto do projeto que fazem parte. É como se fossem “entidades fracas” em um modelo de entidade e relacionamento (pequena lembrança nostálgica da minha formação acadêmica). Criar subprojeto pode ser uma estratégia bastante interessante no desmembramento de projetos que possuem vários entregáveis e várias etapas a serem vencidas, porém não se pode esquecer que cada subprojeto deverá entregar o seu produto ou serviço final como se fosse um projeto, na concepção da palavra, mas este produto só fará sentido se o projeto “pai” for também finalizado e entregue.

Nas próximas postagens estaremos explorando os conceitos de PMO (escritórios de projetos) e as estruturas organizacionais existentes em empresas que desenvolvem projetos.

Vamos em frente!!!

PMBOK - Introdução (Parte 1)

Conforme já havíamos colocado na publicação anterior, a partir deste texto estaremos aprofundando o conhecimento nas metodologias, melhores práticas e bibliotecas que, juntas, nos ajudarão a montar uma gestão de TI inteligente!!

Para estrear esta nova fase do nosso blog, falaremos sobre o PMBOK, um guia que identifica um conjunto de práticas e processos referentes ao gerenciamento de projetos amplamente reconhecidos como boas práticas pelo mercado.

Antes de qualquer coisa, necessitamos deixar claro o que significa fazer projetos. Fazemos projetos nas nossas vidas particulares, nas nossas vidas profissionais e até na nossa vida amorosa. Sempre que queremos fazer algo novo, dar um salto de qualidade ou ir além do que estamos acostumados a fazer, invariavelmente e até mesmo de forma inconsciente utilizamos projetos para concretizar esses sonhos ou objetivos. Nas organizações o mesmo acontece. A forma mais eficaz de implementar os objetivos estratégicos, onde há a necessidade de se fazer algo novo, além do operacional (dia a dia), é por meio de projetos.

Um projeto pode ser definido como um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo. É temporário porque deve ter um início e um fim bem definido. Isto vai diferenciá-lo das rotinas operacionais do dia a dia, onde não há um limite de tempo, pois as tarefas acontecem ciclicamente sem um fim determinado. Deve buscar a criação de um produto, serviço ou resultado exclusivo porque tem o objetivo de dar um salto de qualidade, sair de um patamar para outro mais alto. Todavia, é importante deixar claro que produto, serviço ou resultado exclusivo não significa, obrigatoriamente, algo inédito. A presença de elementos repetitivos não muda a singularidade fundamental do trabalho do projeto. Podemos exemplificar esta ideia em relação ao lançamento de um novo modelo de carro. O desenho do novo carro é sem dúvida alvo de um projeto, pois, apesar de carro não ser algo inédito, o trabalho de se desenhar um novo carro gerará um produto singular e exclusivo. Já o processo de produção em série deste carro, após a sua concepção e lançamento não será um produto de um projeto, e sim das rotinas operacionais da montadora.

Continuaremos com a introdução e conceitos básicos de projetos e do PMBOK nas próximas publicações.... Não percam!!!!

Planejando os Próximos Passos

Como vocês podem perceber, este blog procura fazer um encadeamento de ideias, como em uma revista eletrônica. Iniciamos o blog falando um pouco sobre a realidade do nosso mundo e como ela afeta as empresas e as áreas de TI. Depois demos início a uma série de postagens que falavam sobre a matriz de governança de TI, instrumento importantíssimo para identificarmos quem manda no quê dentro da organização que trabalhamos. Falamos de cada um dos domínios de TI, dos possíveis arranjos de governança (arquétipos) e de como montar e analisar a matriz confeccionada. Preferimos fazer desta forma, antes de mergulharmos nos modelos e metodologias de mercado, uma vez que, a definição de qual modelo utilizar depende da realidade de cada organização, mapeada pela matriz de governança de TI.

Tendo explorado toda a matriz de governança, iniciamos uma conversa sobre qual a melhor forma de se implementar esta tal governança de TI. Comentamos de onde ela se origina e de que forma pode ser implementada (endógena ou exógena).

Finalmente mostramos a inter-relação entre os principais modelos e como se complementam dentro do processo de implementação da governança de TI. Agora estamos prontos para mergulhar em cada um dos principais modelos de mercado. Para facilitar o trabalho, bolei a seguinte sequência que acho que irá agradar a quem lê este blog:

1 – Gerência de Projetos – PMBOK
2 – CMMI
3 – Mps.Br
4 – APF
5 – ITIL V2
6 – ITIL V3
7 – COBIT

Este é o planejamento inicial, pode ser que no decorrer do percurso algumas mudanças aconteçam, mas vamos tentar segui-lo. Sigam-me os bons!!!

Integração entre Modelos – Parte 4 (Modelos Genéricos)

Finalizando as postagens sobre integração entre modelos, falaremos sobre os chamados “Modelos Genéricos”. Estes modelos, normas, padrões e melhores práticas são considerados genéricos porque podem ser utilizados em uma vasta série de assuntos, não apenas TI. No caso da governança de TI, os modelos genéricos servem de alicerce para a implementação de uma gestão de TI eficaz.

Dentre muitos modelos, padrões e normas que existem, selecionamos aqueles que estão presentes na maioria das empresas que implementaram a sua governança de TI. Esses modelos/padrões estão destacados de vermelho na figura abaixo. Passemos a descrever um pouco sobre cada um deles.


Fonte: Curso de GTI - Cathedra

ISO/IEC 9001 – Uma das normas mais famosas no mercado. Estabelece um modelo de gestão da qualidade, cujo objetivo principal é prover confiança de que a empresa poderá fornecer, de forma consistente e repetitiva, bens e serviços de acordo com o que foi especificado.

ISO/IEC 27000 - É um padrão para a gestão da segurança da informação. Seu objetivo é ser usado em conjunto com ISO/IEC 17799, o código de práticas para gerência da segurança da informação, o qual lista objetivos do controle de segurança e recomenda um conjunto de especificações de controles de segurança. A ISO/IEC 27000 é a primeira norma em uma família de padrões referentes à segurança da informação (27000 até 27006).

PMBOK – Já vimos anteriormente que o mapeamento estratégico estabelece metas a serem atingidas pelas organizações. Normalmente, estas metas, frutos de objetivos estratégicos, não estão no âmbito do dia a dia das organizações. Na verdade são saltos de qualidade que devem ser implementados por meio de projetos. O PMBOK identifica um conjunto de melhores práticas, ferramentas, técnicas e conhecimentos que são aplicados nas atividades do projeto a fim de atender aos seus requisitos, sempre procurando equilibrar a chamada “tripla restrição” (escopo, tempo e custo).

IN 4/SLTI – A instrução normativa número 4, da Secretaria de Logística e Tecnologia da Informação do Ministério do Planejamento, dispõe sobre o processo de contratação de serviços de Tecnologia da Informação pela Administração Pública Federal direta, autárquica e fundacional. Esta instrução normativa tem sido muito utilizada pelo TCU nas auditorias realizadas nos órgãos públicos.

Bem amigos, com esta postagem finalizamos a nossa “viagem” pela integração entre os modelos. Espero que vocês tenham captado a “alma” do negócio. Vamos nos aprofundar em alguns desses modelos e metodologias a fim de darmos mais sustância (como se diz lá na minha terra) ao nosso conhecimento. Vamos nessa?!!!

Integração entre Modelos – Parte 3 (ITIL e CMMI)

Continuando o nosso passeio pela integração entre modelos, vamos falar um pouco de dois modelos consagrados que de uma certa maneira se complementam(ver os destaques em vermelho da figura abaixo). Um por ter um foco na parte de desenvolvimento (CMMI) e outro com a visão mais voltada para serviços de TI (ITIL)(um pezinho mais voltado para o lado da infraestrutura).

Por serem modelos bastante maduros, é claro que possuem algumas áreas de interseção, como por exemplo a área que trata do planejamento. Além disso é possível perceber que algumas vezes um modelo invade a área de maior domínio do outro. Exemplo disso é a existência de um livro, no ITIL, voltado para o desenvolvimento de aplicações, foco do CMMI, e a existência, no CMMI, de áreas de processos preocupadas com mudanças e configurações, área bem explorada pelo ITIL.

Como já dito anteriormente, iremos abordar mais profundamente esses modelos mais para frente, porém neste momento o que nos interessa é perceber que a combinação de modelos fará com que a governança de TI fique completa e adaptável à realidade de cada organização.


Fonte: Curso de GTI - Cathedra

O ITIL é uma biblioteca de melhores práticas que foi criada no governo britânico após verificação que existia no mundo um aumento da dependência da TI em relação ao alcance dos objetivos estratégicos das organizações. Segundo a visão do ITIL, a TI deve ser vista como serviço, assim como a energia elétrica ou a telefonia. Todas as pessoas esperam que, ao apertar o interruptor, a lâmpada irá acender, assim como todos esperam que ao tirarmos um telefone do gancho haverá um sinal de linha para que possamos fazer a chamada. Da mesma forma a TI tornou-se um requisito básico para a operação do negócio, ou seja, é esperado que as organizações utilizem a TI para poderem funcionar. Sob esta ótica, o ITIL procura descrever o que as organizações devem fazer para assegurar o uso da TI conforme acordos de níveis de serviços firmados.

Já o CMMI aborda um modelo de melhoria no processo de construção de software (qualidade). Este modelo mostra para as organizações o que deve ser feito para se produzir softwares com qualidade e que atendam os objetivos estratégicos da empresa. O CMMI propõe duas formas de verificar a capacidade e a maturidade dos processos de desenvolvimento, a saber: uma contínua e outra por estágios. Na primeira, cada área de processo é avaliada individualmente quanto ao seu grau de capacidade. Já na segunda, o CMMI propõe a existência de um platô evolutivo em que cada nível estabiliza e demonstra a maturidade dos processos da organização.

Nas próximas postagens iremos finalizar esta rápida olhada sobre a integração entre modelos. A partir daí faremos um bom mergulho nos principais modelos, enfatizando suas vantagens, áreas de aplicação e seus processos. Não percam!!!

Integração entre Modelos – Parte 2 (COBIT, o modelo guarda-chuva)

Continuando a nossa análise em relação à integração entre os vários modelos e lembrando que neste primeiro momento não mergulharemos profundamente na teoria de cada um deles, nesta postagem estaremos falando brevemente do COBIT.

O COBIT é dividido em quatro domínios, a saber: Planejamento e Organização, Aquisição e Implementação, Entrega e Suporte e Monitoramento e Avaliação. Ele é conhecido como modelo guarda-chuvas porque possui áreas de interseção com vários outros modelos/melhores práticas e porque é o modelo responsável por fazer o alinhamento da TI com o negócio, abrangendo praticamente todas as áreas de atuação da TI. Verificando a figura abaixo, vemos que o COBIT (destacado em vermelho) engloba não apenas as questões técnicas de TI, mas também a parte estratégica. É por meio dos seus quatro domínios que o COBIT monta um ciclo que verifica continuamente o alinhamento da TI aos objetivos do negócio.


Fonte: Curso de GTI - Cathedra

Criado com foco em controle, o COBIT montou uma vasta estrutura de verificação dos elementos que compõe a TI: seus recursos, processos e critérios de informação. Ele é baseado em uma série de métricas que avaliam o desempenho da TI em relação aos seus objetivos, tanto no nível operacional, quanto nos níveis tático e estratégico. Em sua versão 4.0, o COBIT preconiza 34 processos divididos nos seus quatro domínios e mais uma série de atividades que estão ligados a estes processos. Falaremos mais aprofundadamente sobre o COBIT mais para frente, por enquanto o que é importante saber é que este modelo será bastante utilizado quando formos colocar em prática a nossa governança de TI. Como já dissemos antes, pode ser que nem tudo do COBIT seja utilizado, mas veremos que há muitas coisas que podem nos ajudar a montar uma gestão de TI inteligente!!!

Nas próximas postagens continuaremos viajando na integração entre os modelos. Não percam!!!

Integração entre Modelos

Quando comecei a implementar a governança de TI em uma das maiores empresas de saúde suplementar do Brasil, uma das grandes dificuldades que tive que enfrentar foi a escolha do modelo de mercado a ser utilizado. Existem no mercado uma grande variedade de modelos, metodologias e melhores práticas e cada uma delas pode servir para uma determinada área ou um determinado processo organizacional. Diante deste dilema tive que estudar os modelos para depois correlacioná-los de forma a entender como aplicá-los eficientemente.

Aqui no blog resolvi fazer diferente e começar do fim para o começo. Ainda veremos os modelos mais a fundo, mas inicialmente vamos mostrar como os principais deles se interagem. É bom lembrar que existem muitos outros, além desses que serão abordados, mas acho que com o que vamos apresentar dá para fazer uma boa implementação da governança de TI. Nesta postagem vamos explicar as seguintes elementos da figura abaixo (destacados em vermelho): BSC corporativo, BSC de TI (Estratégico), BSC de TI (Desenvolvimento) e BSC de TI (Suporte).


Fonte: Curso de GTI - Cathedra

O Primeiro passo, como já dito nas outras postagens, é o mapeamento da matriz de governança. Esta matriz servirá como base para identificar os pontos fortes e fracos da área de TI em relação aos seus domínios(ver postagens sobre a matriz de governança de TI). Ela será útil, especialmente, quando o CIO tiver em suas mãos o mapa estratégico da organização.

O mapa estratégico da organização é mostrado na figura acima como sendo o produto do item BSC corporativo e possui, entre outras coisas, as diretrizes e metas do negócio (Normalmente, o Balanced scorecard - BSC é a ferramenta utilizada para fazer o planejamento estratégico das empresas). Diante de um mapa estratégico de negócio fica mais tranquilo montar o BSC de TI. No primeiro momento, o BSC da TI deve estar focado na identificação das oportunidades de negócio que a TI deverá trabalhar, ou seja, estará no plano estratégico. É exatamente neste momento que o CIO irá verificar o que deve ser feito (com base no BSC do negócio) e como ele poderá influenciar para que os objetivos sejam alcançados (por meio da análise da matriz de governança de TI). Medidos os pontos fortes e fracos, e gerado um guia estratégico de TI, são feitos os mapeamentos da TI para a área de Desenvolvimento e para a área de Suporte.

Nas próximas postagens focaremos nas metodologias e melhores práticas que nos auxiliam a montar a parte estratégica da TI assim como as ações voltadas para a área de Desenvolvimento e de Suporte.