PMBOK – Introdução (Parte 4) – Estruturas Organizacionais 1

Um dos grandes fatores que determinará como os projetos serão tocados é o ambiente organizacional no qual os mesmos estarão inseridos. Nesta postagem falaremos sobre as estruturas organizacionais que encontramos nas empresas e suas consequências para os projetos tocados nas mesmas.

O PMBOK descreve cinco tipos diferentes de estruturas, a saber:

1 – Funcional.
2 – Projetizada.
3 – Matricial Fraca.
4 – Matricial Balanceada.
5 – Matricial Forte.

A estrutura Funcional, também chamada de estrutura Funcional Clássica, retrata as empresas onde há uma hierarquia funcional forte. Neste tipo de estrutura, cada funcionário possui um superior bem definido e está alocado em “caixinhas” bem especializadas (área contábil, área de marketing, etc). Os projetos que são tocados nestes tipos de organização, normalmente possuem escopos restritos aos limites da função. Outra característica interessante é que o gerente de projeto é, na verdade, um papel executado pelo gerente funcional, ocupando apenas parte do seu tempo para o projeto. A figura abaixo mostra este tipo de estrutura.

Na outra ponta da corda, existem as empresas que utilizam uma estrutura Projetizada. Nesta estrutura, os membros das equipes são colocados juntos. A maior parte dos recursos da organização está envolvida no projeto e os gerentes de projetos possuem grande independência e autoridade. As empresas que adotam este modelo possuem também áreas com especializações, assim como as Funcionais, mas essas áreas servem de apoio para os projetos. A figura abaixo mostra como funciona a estrutura projetizada.

Para não ficarmos com textos muito extensos, continuaremos na próxima postagem com as três estruturas matriciais que estão faltando... Sigam-me os bons!!!!

PMBOK – Introdução (Parte 3) - PMO (Project Management Office)

O PMO (Project Management Office) ou Escritório de Projetos, no bom e velho português, é uma unidade organizacional que pode centralizar e coordenar o gerenciamento de projetos sob seu domínio. Na verdade verdadeira (como se dizia na minha época de criança), não existe uma regra fixa para a montagem do Escritório de Projetos. Cada organização pode e deve montar esta unidade de acordo com a sua maturidade em relação à gerência de projetos e à cultura organizacional.

Existem alguns tipos diferentes de PMOs. Um tipo muito comum de Escritório de Projetos é aquele que tem uma função educativa e de padronização, onde atua como suporte ao gerenciamento de projetos por meio de treinamentos, políticas, procedimentos e padrões. Um exemplo disso é o PMO instituído no estado de Minnesota – USA. Neste caso, conforme figura abaixo, o Escritório de Projetos é responsável pela institucionalização dos processos de gerência de projetos, a fiscalização se os mesmos são seguidos, o treinamento das pessoas envolvidas, a consultoria em relação à padronização dos processos e a definição de práticas a serem seguidas por todos os projetos.

Outro tipo de PMO é aquele onde a área atua gerenciando diretamente os projetos, com responsabilidade pelo alcance de seus resultados. Neste caso, o Escritório de Projetos cuida também do gerenciamento de portfólio (ver postagem anterior), onde é feita uma análise para verificar o alinhamento dos projetos que estão sob sua responsabilidade e os objetivos estratégicos da organização.

Como podemos avaliar, a forma e o poder do Escritório de Projetos dependerá da estrutura da organização em que se encontra e da forma como as pessoas estão acostumadas a trabalhar com projetos. Normalmente, o que se vê nas organizações é um processo evolutivo, onde o PMO inicia-se como um institucionalizador das práticas de gerência de projetos. Em empresas mais maduras, em termos de gerência de projetos, os PMOs passam a executar papéis de maior responsabilidade e assumem para si o controle dos projetos estruturantes e que terão impactos mais altos nos objetivos estratégicos.

Nas próximas postagens viajaremos sobre as estruturas organizacionais existentes e como o gerenciamento de projetos interage com elas... Não percam...

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!!!