F é r i a s ! ! ! !

Nosso blog vai parar durante o mês de Janeiro de 2011!!! Após praticamente 3 anos sem férias (isso mesmo que você leu!!!), vou tirar umas merecidas férias com minha família. Como vou para uma praia de uma pequena cidade do nordeste, não tenho esperança de ter internet com acesso rápido para continuar as postagens. Na verdade, nem se tivesse internet, eu teria coragem de fazê-lo, pois, como diria meu avô: “não se vende o que não se pode comprar!”. Como não poderei comprar outros momentos de férias, tenho que aproveitá-los ao máximo...

Mas não fiquem tristes, voltaremos em Fevereiro com todo o gás e continuaremos com a incrível viagem pelo ITIL e pelos os outros modelos que serão abordados no ano de 2011.

Um feliz Ano Novo para todos nós!!!! e...

... SIGAM-ME OS BONS!!!!!

ITIL V3 – Introdução e Conceitos – Papéis e Matriz RACI

Nesta postagem estaremos finalizando a parte de introdução e conceitos iniciais do ITIL V3 com dois assuntos muito importantes para esta biblioteca de melhores práticas: os papéis e a famosa Matriz RACI.

Papéis


Cada processo do ITIL pode definir quantos papéis forem necessários para sua execução, mas existem dois papéis, definidos como “papéis genéricos”, que são vitais para qualquer processo do ITIL: o papel de Dono do Processo e o papel de Dono do Serviço. A seguir, vamos detalhar melhor cada um desses papéis.

• Dono do Processo

Cada processo deve ter apenas um dono. Este dono é responsável por garantir que seu processo esteja sendo executado segundo o que foi acordado e documentado e está alcançando os objetivos definidos no próprio processo. Existem tarefas que são de responsabilidade do dono do processo, dentre elas podemos citar as seguintes: documentar e divulgar o processo, definir os Principais Indicadores de Desempenho (PIDs ou KPIs), melhorar a eficiência e eficácia do processo, fornecer entradas para o Plano de Melhoria do Serviço, garantir que toda a equipe tenha recebido o treinamento necessário sobre o processo e garantir que o processo seja regularmente revisado e reexaminado.

No mundo real das organizações, o dono do processo tem que ter, no mínimo, uma certa influência para que possa garantir que seu processo esteja sendo executado corretamente. Em outras palavras, processos cujos donos são “oreias secas” (como se diz lá no cerrado) tendem a não conseguir com que seus processos sejam executados dentro da organização.

Uma observação importante: Dono do Processo é diferente de Gerente do Processo. Este é um braço operacional que fará com que aquele alcance os objetivos do processo.

• Dono do Serviço

Cada serviço deve ter apenas um dono. Este é “o cara” em relação a um determinado serviço. Na verdade, este papel é quem responde pela qualidade final do serviço e presta contas sobre o mesmo. O Dono do Serviço enxerga o serviço como um todo e, assim como o Dono do Processo, possui uma série de responsabilidades, como por exemplo: fornecer aos atributos do serviço (desempenho, disponibilidade, etc.), ser o ponto de escalação para incidentes maiores, representar o serviço em reuniões do Comitê Consultivo de Mudanças, participar em reuniões externas para revisões de serviços com as áreas de negócio, etc.

É importante salientar que o Dono do Serviço não é, obrigatoriamente, quem faz o gerenciamento de nível de serviço.

Matriz RACI


A matriz RACI é um modelo usado para ajudar a definir papéis e responsabilidades. RACI é um acrônico para as quatro funções principais. Pera aí!!!! acrônico??? Essa eu fui longe não??? Mas vamos seguir adiante... hehehe. Bom, como estávamos dizendo, as quatro funções principais são:

• Responsável → Pessoa(s) responsável(eis) por fazer com que o trabalho seja feito. São os que colocam a mão na massa!

• Accountable → É quem presta conta pela atividade.

• Consultado → Pessoas que são consultadas antes da execução da tarefa pois suas opiniões são importantes para a execução da atividade.

• Informado → Pessoas que se mantêm atualizadas constantemente. Normalmente são informadas depois da execução da atividade.

Na Matriz RACI, representada na figura acima, podemos verificar que uma série de informações estão dispostas em forma de tabela, o que facilita a identificação dos responsáveis por cada tarefa dentro de cada processo do ITIL. Apesar disso, existem potenciais problemas relacionados ao modelo RACI que devem ser tratados. Dentre eles podemos citar: ter mais de uma pessoa que presta conta (Accountable) por um processo (na prática, processo com dois donos na verdade não tem nenhum), delegação de responsabilidade ou prestação de contas sem autoridade necessária para tanto, foco na correlação de processos e atividades com os departamentos, etc.

Finalizamos assim os conceitos iniciais, a partir das próximas postagens falaremos genericamente do ciclo de vida do serviço para depois entrarmos com tudo em cada uma das etapas deste ciclo. Não desanimem!!!!

ITIL V3 – Introdução e Conceitos – Funções e Processos

Continuando o alinhamento dos conceitos iniciais do ITIL V3, veremos nesta postagem mais duas definições importantes desta biblioteca de melhores práticas: funções e processos.

Funções

Na visão do ITIL, funções são “unidades da organização especializadas em executar determinados tipos de trabalho e são responsáveis por resultados específicos”. Elas são independentes e auto-suficientes em habilidades e recursos necessários para o seu desempenho. Estamos falando de um conceito lógico, mais genérico, como as estruturas organizacionais dotadas de pessoas, conhecimento e recurso para execução de uma tarefa.

Existe uma distinção importante entre Função, Grupos, Equipes, Departamentos, Divisões e Papéis. A definição de Função já foi descrita no parágrafo anterior, já os Grupos referem-se a uma ou mais pessoas que possuem um propósito comum, não obrigatoriamente da mesma área. Equipe é algo mais formal do que o Grupo, pois tem responsabilidades mais estruturadas. Departamento e Divisões são estruturas formais. Normalmente, uma Divisão possui um ou mais Departamentos. Por fim, Papéis, que serão melhor aprofundado em outra postagem, são as atividades ou lista de atribuições de uma determinada pessoa, grupo ou equipe. Para o ITIL, quem define os papéis são os processos.

Processos

Na visão clássica, também seguida pelo ITIL, processo é “um conjunto estruturado de atividades destinadas a cumprir um objetivo específico” que recebem uma ou mais entradas definidas(os chamados inputs) e as transformam em resultados definidos(os chamados outputs). Normalmente um processo não existe sozinho. Na verdade, ele interage com uma série de outros processos.

No caso do ITIL, os processos são aplicados durante todo o Ciclo de Vida do Serviço (não se apavorem com este termo, entraremos em mais detalhes em futuras postagens!). Sob este aspecto faz-se necessário considerar o processo todo ou como um processo se encaixa em outro processo.

Tendo uma visão genérica sobre um modelo de processo do ITIL, todo processo deve ter um dono, normas ou políticas bem definidas, objetivos (pelo menos um) para ser alcançado, ser documentado e possuir indicadores que permitam medir seu desempenho. Além disso, para que possa ser executado, um processo deve definir as suas atividades, procedimentos e instruções, suas métricas, seus papéis e uma forma de identificar melhorias contínuas. Por fim, para que possam ser viabilizados, os processos devem contar com recursos e habilidades ou capacidades para que funcionem adequadamente.

Neste modelo genérico de processo, o ITIL identifica quatro importante características de processos que descrevemos abaixo:

• Mensurável: Todo processo deve ser capaz de ser medido de forma relevante.

• Entrega resultados específicos: Os processos devem entregar resultados previsíveis, dentro do objetivo para o qual foi criado.

• Entrega resultados primariamente para clientes ou stakeholders: Todo processo deve ter o foco principal no cliente, que pode ser interno ou externo.

• Responde a um evento específico: Todo processo possui um ou mais gatilhos ou agentes que fazem com que o mesmo aconteça.

Pessoal, sei que esses primeiros conceitos podem parecer chatos e repetitivos, mas são vitais para o entendimento de todo o modelo. Não percam os próximos capítulos pois entraremos em partes interessantes que utilizarão os conceitos que estamos colocando nessas primeiras postagens! Sigam-me os bons!!!!

ITIL V3 – Introdução e Conceitos – Boas Práticas e Gerenciamento de Serviço

Já vimos como o ITIL define um serviço de TI, agora vamos passar pelas definições de Boas Práticas e de Gerenciamento de Serviço.

Boas Práticas

Prática, na visão do ITIL, é uma maneira de se trabalhar, ou melhor, uma forma como o trabalho deve ser feito. As práticas incluem, normalmente, atividades, processos, funções, modelos e orientações. Tendo esta definição em mente, podemos concluir que Boas Práticas são atividades ou processos comprovados e utilizados com sucesso por diversas organizações. ITIL é um exemplo de Boa Prática.

Todavia, não podemos confundir Boa Prática com Norma. A Norma é algo obrigatório, as Boas Práticas não. Na verdade, o uso de Boas Práticas garantem naturalmente a execução das Normas. O ITIL define-se como sendo uma boa prática onde cada empresa deve adotar e adaptar à sua realidade no que diz respeito a serviços de TI.

Gerenciamento de Serviço

Existem inúmeras definições no mercado para gerenciamento de serviço, porém na visão do ITIL, Gerenciamento de Serviço é um conjunto de habilidades organizacionais especializadas (entenda-se processos, conhecimento, etc) para prover valor aos clientes na forma de serviços.

O gerenciamento de serviços enfrenta quatro desafios, que na verdade são características dos serviços, que influenciam de forma determinante como as empresas devem atuar para gerenciá-los. Descrevemos abaixo estes quatro desafios do gerenciamento de serviços ou quatro características dos serviços de TI:

• Intangibilidade – Um serviço é mais difícil de medir, de definir fronteiras e de definir expectativas do que produtos. Exemplo: Na compra de uma passagem aérea, a compra não é da passagem (papel ou e-mail) e sim da viagem. Esta viagem possui várias variáveis, que dependem não apenas na empresa, mas também de quem compra na hora de definir se atendeu as expectativas, etc.

• Inseparabilidade – Este termo refere-se a relação entre o consumo e a entrega de um serviço. O momento da produção e do consumo do serviço não podem ser separados. Diferente de um produto, onde há esta divisão clara (produção e consumo), um serviço, ao mesmo tempo que está sendo produzido está sendo consumido. Tomemos como exemplo o serviço de disponibilizar uma Rede. O serviço de rede ao mesmo tempo que está sendo produzido, é consumido pelos usuários.

• Variabilidade – O mesmo serviço pode ser entregue de formas diferentes. Voltemos ao exemplo da viagem aérea. Dependendo do dia e do horário, uma mesma companhia pode ter atraso ou não, pode ter fila ou não e vai atender suas expectativas de forma diferente cada vez que o serviço for consumido.

• Pericibilidade – Um serviço não pode ser estocado. No exemplo acima, após o avião decolar aquele serviço de viagem não consegue ser reutilizado para o mesmo voo, caso um passageiro não consiga embarcar. Será necessário um outro serviço de viagem para atender a sua necessidade.

Com esses conceitos bem estruturados, continuaremos nas próximas postagens a equalizar as definições do ITIL para que possamos entrar com um bom nível de conhecimento no ciclo de vida do serviço... Vamos nessa?!!!

ITIL V3 – Introdução e Conceitos – O que é um serviço?

Para o ITIL, na sua terceira versão, a definição oficial de serviço é a seguinte:

“Um serviço é um meio de entregar valor ao cliente, facilitando a obtenção dos resultados que os clientes querem alcançar sem que estes assumam a propriedade dos custos e riscos inerentes.”

Achou complicado? Não entendeu nada? Calma, calma... Vamos por partes. Esta definição possui uma série de coisas importantes descritas de forma sucinta que precisamos nos atentar principalmente quando fornecemos serviços de TI.

A primeira informação importante, destacada no texto, diz respeito a expressão “entregar valor”. Entregar valor tem o sentido de fornecer um benefício que é compreendido pelo cliente, algo como o serviço de telefonia fixa e celular, os correios, etc. Este benefício deve ajudar o cliente, segundo termo em destaque, a alcançar um determinado objetivo definido por ele. O terceiro trecho destacado diz respeito à propriedade dos custos e riscos inerentes ao serviço oferecido ao cliente. Quando contratamos um serviço não nos importamos com os riscos e custos inerentes a ele, vamos exemplificar para melhor explicar o que queremos dizer.

Os Correios oferecem dois serviços distintos, o SEDEX e o SEDEX 10. Consideremos, numa hipótese fictícia, duas empresas que fazem vendas pela internet, uma vende livros e a outra medicamentos. Ambas enxergam o correio como uma provedora de serviços e cada uma escolhe o benefício, ou serviço, que irá ajudá-la a alcançar os seus objetivos da forma mais eficiente. A empresa que vende medicamentos prefere utilizar o serviço de SEDEX 10, devido a natureza do produto que comercializa, enquanto a empresa que vende livro prefere utilizar o SEDEX normal. Os riscos associados a logística de entrega do SEDEX 10 provavelmente são diferentes dos riscos do SEDEX normal, mas isso não é um problema das empresas que utilizam os serviços e sim dos Correios. Os custos para a produção do serviço também são de responsabilidade dos Correios, que negocia um valor para as empresas que avaliam as suas necessidades e escolhem pela alternativa que melhor os atenda.

Hoje em dia quase tudo é comercializado na forma de serviços. As pessoas contratam os níveis de serviço e não o produto simplesmente, ou seja, você deseja as características de um determinado produto e não uma caixa fechada.

Sacou quão longe o pessoal da OGC pensou? Essa é uma das razões do ITIL ter se tornado tão conhecido mundialmente e tão utilizado pelas empresas de TI.

Na próxima postagem veremos os conceitos de boas práticas e gerenciamento de serviços. Sigam-me os bons!!!!

ITIL V3 – Introdução e Conceitos – Histórico do ITIL

Começamos a partir desta postagem uma grande viagem por uma das mais espetaculares bibliotecas de melhores práticas para gerenciamento de serviços de TI!!! A biblioteca ITIL!!! Aliás, o correto, em português, seria dizer a ITIL e não o ITIL, uma vez que a mesma é uma biblioteca, mas não vamos ficar brigando com aqueles (inclusive eu mesmo) que tratam como o ITIL, como é mais utilizado pelo mercado (alguns dizem que é o modelo de melhores práticas, o framework, etc,etc,etc).


O ITIL, ou a ITIL, nasceu há 20 anos na Inglaterra (oficialmente tem 20 anos de vida, mas as práticas de gerenciamento existem a muito mais tempo). Na década de 80, a primeira ministra daquele país, Margareth Thatcher, mais conhecida como a Dama de Ferro (pense numa mulher bruta...) iniciou uma mudança na estrutura do governo inglês com a privatização de algumas empresas estatais, as famosas British --alguma coisa-- (BP – British Pretolium, British Airways, etc). Para gerenciar o funcionamento dos mercados que estavam sendo privatizados, foram criadas as agências reguladoras. Uma delas, a CCTA (uma espécie de ANATEL britânica), reuniu empresas públicas, privadas, fundações, entre outras organizações e poderes públicos para identificar quais seriam as melhores práticas no gerenciamento de serviços de TI. Desta reunião saiu a versão 1 do ITIL, em 1990.

A biblioteca foi, aos poucos, conquistando o mercado europeu, especialmente a Alemanha, França e Holanda. Apenas no final dos anos 90, o ITIL entrou nos Estados Unidos. Em 2000 foi lançada a versão 2 da biblioteca. Nesta versão foram feitos resumos e integrações dos vários processos descritos na versão anterior. A versão 2 da ITIL ganhou o mundo e se popularizou como o framework de melhores práticas no gerenciamento de entrega de serviços em TI mais utilizados pelas organizações (existem muitas outras). A CCTA passou a se chamar OGC (Office of Govermment Commerce), cujo foco é adotar práticas para a eficiência da gestão pública. A OGC é a detentora da marca ITIL, porém ela não se interessa em montar cursos, fazer exames de certificação, implementar a ITIL mundo afora, etc. Isso fica a cargo de uma estrutura que rodeia as decisões tomadas pela OGC

Em 2007 foi lançada a versão 3 do ITIL. Esta versão tem uma visão mais ampla de governança de TI, já que, nas versões anteriores o foco principal era a parte de infraestrutura de TI. Como o tempo médio de vida de uma versão do ITIL é de 7 a 10 anos, acredito que o estudo da V3, ao invés da V2 será mais útil para os nossos leitores e para as empresas que pensam em gerenciar os serviços de TI com base nos processos descritos no ITIL.

Vamos juntos nessa nova e interessante viagem!!!!!

Aniversário de 1 ano!!!

Completamos, neste dia 19 de Novembro, o primeiro aniversário desse blog!!! Idealizado a partir de uma antiga ideia de disseminar o conhecimento e de ajudar as organizações a fazerem uma gestão de TI inteligente, o nosso blog alcança esta importante marca tendo passado por assuntos de grande relevância no contexto da governança de TI. Desejo vida longa ao blog com muitas informações, dicas, exemplos e experiências. Tudo isso sem deixar de lado o bom humor...

Sigam-me os bons!!!!!

Mudança no Planejamento Inicial

Pessoal, na postagem do dia 12 de março de 2010, após passarmos pelos conceitos de governança de TI e pela interação entre as principais metodologias, fizemos um planejamento dos tópicos que seriam abordados no nosso blog. Naquele momento a sequência colocada me parecia uma sequência lógica razoável para que pudéssemos navegar pelas metodologias, melhores práticas e bibliotecas existentes no mercado. Porém, como a única certeza que temos na vida é que as coisas mudam, após passarmos por todo o processo de gerenciamento de projetos acho que uma mudança no planejamento inicial se faz necessário. Explico.

Havíamos colocado a seguinte sequência para o nosso blog:

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

A lógica era trabalharmos a área de desenvolvimento e depois a área de infraestrutura. O gerenciamento de projetos, por servir as duas áreas, ficou sendo o primeiro tópico a ser abordado. Após passarmos pelo PMBOK, verifiquei que o ITIL V3 está muito mais amplo, abrangendo uma grande parte da governança de TI. Diante dessa constatação, acho que será mais produtivo se trouxermos com maior prioridade o ITIL V3 e o COBIT, uma vez que estaríamos continuando toda a lógica inicial do blog (Gestão de TI inteligente). Nessa nova estratégia, não faz mais sentido trabalharmos com o ITIL V2, já que, apesar de ser bastante utilizada pelas organizações, esta versão está em processo de substituição pela V3.

Após fecharmos os assuntos mais ligados à governança, entraremos na parte mais focada na qualidade de software e processo de desenvolvimento. Dito tudo isso, o novo planejamento ficará da seguinte forma:

1 – Gerência de Projetos – PMBOK (Concluído)
2 – ITIL V3
3 – COBIT
4 – CMMI
5 – MPS.Br
6 - APF

Vamos pra frente que atrás vem gente!!!!!

PMBOK – Diferenças entre a 4a e a 3a edição – Parte 2

Nesta postagem estaremos finalizando a comparação entre a 4a e a 3a edição do PMBOK. Abordaremos as áreas de conhecimento que não foram contempladas na postagem anterior. Vamos lá?

Gerência de Riscos

Fonte: Curso Cathedra

Gerência da Qualidade

Fonte: Curso Cathedra

Gerência de Recursos Humanos

Fonte: Curso Cathedra

Gerência das Comunicações

Fonte: Curso Cathedra

Processo: Identificar as partes interessadas.

Este novo processo da 4a versão tem como objetivo principal identificar todas as pessoas e/ou organizações que possam ser afetadas pelo projeto. Além disso, este processo é responsável por fazer a análise e a documentação dos níveis de interesse, expectativas, importância e influência de cada parte interessada identificada.

Gerência das Aquisições

Fonte: Curso Cathedra

Caros leitores, após longa caminhada é com imensa satisfação que informo que esta postagem finaliza tudo o que tinha para compartilhar com vocês no que se refere à gerência de projetos. Não significa que o mundo da gerência de projetos se resuma aos tópicos abordados neste blog, mas acredito que tendo o objetivo de disseminar o conhecimento, o conteúdo aqui postado compõe uma sólida base de informações. Espero que tenham curtido pois, a partir da próxima postagem, estaremos abordando um novo tema dentro do que considero uma Gestão de TI inteligente.

Sigam-me os bons!!!

PMBOK – Diferenças entre a 4a e a 3a edição – Parte 1

Caros leitores, decidimos descrever todos os processos da 3a edição do PMBOK porque esta é, ainda, a versão mais utilizada na prática pela a maioria das empresas. Contudo, não podemos deixar de esclarecer que a 4a edição, lançada em 2008, começa a ganhar espaço no dia a dia das organizações. Dessa maneira, para que possamos deixar o nosso blog sempre atualizado, em relação às melhores práticas e metodologias do mercado, deixamos como tópico final do assunto referente a gerenciamento de projetos, as principais diferenças entre essas duas edições.

Ciclo de vida do projeto

Segundo o PMBOK na sua 4a edição, todos os projetos podem ser mapeados para uma estrutura genérica de ciclo de vida. Conforme figura abaixo, esta estrutura está dividida em: início do projeto, organização e preparação, execução do trabalho do projeto e encerramento do projeto.



Essas fases do ciclo de vida do projeto podem ter as seguintes relações: Sequenciais, sobrepostas e iterativas. De forma geral, em fases sequenciais há a diminuição das incertezas, mas pode eliminar a possibilidade de redução do cronograma. Em fases sobrepostas pode existir o retrabalho, se uma fase subsequente progrida antes que as informações corretas sejam disponibilizadas pela fase anterior. Finalmente, em fases iterativas, apenas uma fase está planejada a qualquer momento e o planejamento da próxima fase é feito à medida que o trabalho avança. Neste tipo de ciclo de vida, o escopo é gerenciado por entregas contínuas de incrementos do produto e priorização de requisitos para minimizar riscos e aumentar o valor comercial do projeto.

Áreas de conhecimento

Em relação ás áreas de conhecimento, o PMBOK padronizou os nomes dos processos, alterando os nomes de todos aqueles que não começavam com um verbo no infinitivo. Agora, todos os processos seguem esta nova regra, como por exemplo, o processo “Controle integrado de mudanças” que passa a se chamar “Realizar o controle integrado de mudanças”.

Alguns processos foram extintos, outros criados e ainda outros mudaram de grupo de processos. A seguir colocamos quadros com as alterações ocorridas em cada um das áreas de conhecimento.

Gerência de Integração

Fonte: Curso Cathedra

Gerência de Escopo

Fonte: Curso Cathedra

Processo:Coletar os requisitos

Este novo processo tem o objetivo de definir e documentar as funcionalidades do projeto e do produto. Esses requisitos servirão de base para a criação da EAP e pode ser dividida em requisitos do projeto e requisitos do produto.

É importante deixar claro que os requisitos devem ser coletados com detalhes suficientes que permitam que os mesmos sejam medidos durante a execução do projeto.

Gerência de Tempo

Fonte: Curso Cathedra

Gerência de Custos

Fonte: Curso Cathedra

Como costumamos fazer no nosso blog, para evitar postagens longas e enfadonhas, finalizaremos na próxima postagem as diferenças encontradas nos processos de cada área de conhecimento. Não percam!!!!

PMBOK - Coffee Break 2 – Eleições e Amenidades

Após a revisão de todos os processos do PMBOK e antes de colocarmos as diferenças básicas entre a 4a e a 3a edição, vamos fazer mais um coffee break, que ninguém é de ferro!!! Nesta postagem estaremos falando, entre outros, do tema principal pós Copa do Mundo, as eleições.

• Eleições 1 – Tiririca no poder...

Pois é, não é que o povo do estado mais rico do Brasil conseguiu eleger Tiririca como deputado federal? Nada contra a pessoa do Tiririca, mas acho que apesar de termos a impressão, em certas ocasiões, que o nosso congresso é um verdadeiro circo, temos que ter limite para não desmoralizarmos de vez as instituições democráticas que regem o nosso país... Deus nos salve!!!

• Eleições 2 – Democracia teen.

Como que por mágica nos pegamos discutindo com amigos, familiares e colegas de trabalho sobre política e soluções para um Brasil melhor. Quem dera o brasileiro (eu inclusive!) tivesse esse interesse todo durante o mandato daqueles que colocamos no poder. Nossa democracia está na puberdade e precisa amadurecer muito ainda...

• Eleições 3 – O que é isso????

Me desculpem os eleitores da Weslian, aqui no DF, mas aquela senhora não tem condição de administrar nem a própria casa, que dirá concorrer a qualquer cargo público (ainda mais governadora!!!). Do lado dela Tiririca parece Albert Einstein... Pense...

• Piadinha feita por Português...

Joaquim:
- Manoel, sabes a última do Brasil?
Manuel:
- Não o pá...
Joaquim:
- Lá você pode votar com qualquer documento, exceto o título de eleitor.
Manuel:
- Estás brincando!!?

PMBOK – Áreas de Conhecimento – Gerenciamento das Aquisições

Após uma longa jornada, chegamos a última área de conhecimento, o gerenciamento das aquisições. Esta área de conhecimento é a responsável por gerenciar os outros recursos que não sejam pessoas ou informações. O gerenciamento das aquisições é composto pelos processos que compram ou adquirem produtos, serviços e/ou resultados e pelos processos que fazem o gerenciamento dos contratos firmados. A seguir exploraremos cada um desses processos.

Processo: Planejar compras e aquisições.

Este processo busca identificar quais, dentre as necessidades do projeto, podem ser melhor atendidas pela compra ou aquisição de produtos, serviços ou resultados.

Perguntinha de vestibular... Quem viria primeiro, compras ou contratações? Na verdade existe uma ordem cronológica entre as compras e contratações, segundo o PMBOK. O primeiro trata das questões estratégicas e o segundo diz respeito as questões operacionais. Por isso, antes das contratações, o projeto deve se preocupar com o que comprar.

Os demais processos do gerenciamento das aquisições serão executados para cada item a ser comprado ou adquirido.

Processo: Planejar contratações.

Este processo tem uma visão mais operacional. Ele é responsável por preparar a documentação necessária para dar suporte a outros dois processos: solicitar repostas de fornecedores e selecionar fornecedores. É importante lembrar que a complexidade e o nível de detalhes dos documentados devem estar de acordo com o valor da compra planejada, os riscos associados a ela e as questões legais referentes à compra ou aquisição de produtos e serviços.

Processo: Solicitar respostas de fornecedores.

É o processo responsável por obter respostas, como cotações e propostas, de possíveis fornecedores sobre como os requisitos do projeto podem ser alcançados. Trocando em miúdos e colocando dentro da realidade brasileira, este processo seria o responsável por publicar o edital de compra e receber as propostas. Simples assim...

Processo: Selecionar fornecedores.

Este processo recebe cotações ou propostas e conforme critério anteriormente definido (menor preço, melhor técnica, técnica e preço, etc) seleciona um ou mais fornecedores que sejam qualificados. Colocando no nosso mundo tupiniquim seria o processo responsável pela adjudicação e contratação do fornecedor.

Processo: Administração de contrato.

Este processo garante que o desempenho do fornecedor atende aos requisitos contratuais. Além disso controla o comprador para que o mesmo atue de acordo com os termos do contrato.

Um fator importante para o projeto é garantir que a natureza legal da relação contratual seja respeitada e que a equipe de gerenciamento do projeto esteja a par das implicações legais das ações tomadas durante a administração de qualquer contrato.

Processo: Encerramento do contrato.

Este processo dá suporte a outro processo visto no gerenciamento de integração, o processo de encerramento do projeto. Ele é responsável por confirmar que o trabalho ou produto contratado foi entregue conforme acordado além de registrar e arquivar as informações pertinentes ao contrato.

A rescisão de um contrato é um caso especial de encerramento do contrato e pode resultar de um acordo mútuo entre as parte ou descumprimento das obrigações de uma das partes.

Bem amigos, como diria Galvão Bueno... Com esta postagem finalizamos a longa e interessante viagem pelos processos do PMBOK. Para finalizar este tema e partirmos para outro tema referente à gestão inteligente de TI, falaremos um pouco das diferenças entre a 3a edição, descrita por nós, e a 4a edição que está começando a ser utilizada nas organizações.

Este é um marco importante para o nosso blog e acredito que os leitores puderam ter uma visão geral e completa deste mundo chamado gerenciamento de projetos.

Sigam-me os bons!!!!

PMBOK – Áreas de Conhecimento – Gerenciamento das Comunicações

Como dito na postagem anterior, se levarmos em consideração que gerenciar projetos é, na verdade, coordenar e gerenciar pessoas para atingirem um determinado objetivo comum, então, fazer com que o fluxo das informações flua de forma eficiente, no tempo correto e para as pessoas certas, é fator crítico de sucesso para que o projeto alcance os seus objetivos. O gerenciamento das comunicações é composto por processos que se preocupam em gerar, coletar, disseminar, armazenar e fazer com que as informações tenham a destinação correta, de forma oportuna e adequada. A seguir detalharemos cada um desses processos.

Processo: Planejamento das comunicações.

Este processo é responsável por determinar as necessidades de informações e comunicações das partes interessadas. É responsável, também, pela identificação do método como se dará a comunicação dentro do projeto e pela elaboração do plano de gerenciamento das comunicações. Este plano fornece algumas informações importantes, como por exemplo: os requisitos de comunicação das partes interessadas; as informações que serão comunicadas, inclusive o formato, o conteúdo e o nível de detalhe; a pessoa responsável pela comunicação; as pessoas ou grupo de pessoas que irão receber as informações, a frequência da comunicação e os métodos ou tecnologias usadas para transmitir as informações (e-mail, memorando, cartas internas, etc).

Processo: Distribuição das informações.

Este processo busca colocar as informações à disposição das partes interessadas no momento oportuno e de acordo com o que foi definido no plano de gerenciamento das comunicações. É importante salientar que este processo não está preocupado em processar as informações e gerar relatórios consolidados, ele apenas faz com que as informações, uma a uma, cheguem a quem é de direito. Poderíamos resumir este processo na seguinte frase: é o processo responsável por fazer a informação circular pelo projeto durante a sua execução. Não podemos deixar de mencionar a possibilidade de surgirem solicitações de informações não previstas. Nestes casos , este processo também será o responsável por resolver o problema.

Processo: Relatório de desempenho.

Diferentemente do processo anterior, este processo faz a coleta dos dados de linha de base e distribui as informações de forma consolidada sobre o desempenho do projeto para as partes interessadas. O relatório de desempenho normalmente reflete uma comparação entre o que foi planejado e o que está sendo executado até o momento. É comum também vermos, neste relatório, as análises de valor agregado, que falamos nas postagens referentes aos processos de gerenciamento de custos.

Não existe uma receita de bolo para se gerar os relatórios de desempenho, depende da necessidade de informação identificada em cada projeto e em cada organização. Há alguns casos em que se exige que os relatórios de desempenho também tragam informações sobre riscos e aquisições, ele também pode ser feito de forma abrangente ou com base nas exceções. Enfim, a necessidade é quem vai determinar como os relatórios de desempenho serão montados e passados para as partes interessadas.

Processo: Gerenciar as partes interessadas.

Este processo trata, basicamente, do gerenciamento ativo das partes interessadas. Gerenciamento ativo significa satisfazer as necessidades das partes interessadas no projeto e resolver problemas com elas. Este processo é importante porque pode reduzir de forma significativa a probabilidade do projeto se desviar do curso por causa de problemas não resolvidos das partes interessadas, além de aumentar a capacidade das pessoas trabalharem em sinergia.

Na próxima postagem estaremos analisando os processos da última área de conhecimento que nos resta verificar. Vamos juntos?

PMBOK – Áreas de Conhecimento – Gerenciamento de Recursos Humanos

Apesar da série “O exterminador do futuro” tentar passar a imagem de que um mundo controlado apenas pelas máquinas seria possível, a verdade é que, hoje em dia pelo menos, sem pessoas, nada pode ser feito!!! Tendo isso como verdade, a área de conhecimento chamada de gerenciamento de recursos humanos trata dos processos que organizam e gerenciam a equipe do projeto. Há quem diga que gerenciar projetos é na verdade, coordenar e gerenciar pessoas para atingirem um determinado objetivo comum.

Processo: Planejamento dos recursos humanos.

Este processo é responsável por determinar os papéis, responsabilidades e relações hierárquicas do projeto, além de criar o plano de gerenciamento de pessoal. A atribuição de responsabilidades pode ser feita para pessoas ou grupos que por sua vez podem ser internos ou externos à organização que executa o projeto.

Processo: Contratar ou mobilizar a equipe do projeto.

O objetivo principal do processo de contratar ou mobilizar a equipe do projeto é obter os recursos humanos necessários para terminar o projeto, ou seja, as pessoas necessárias para fazer o que foi estimado.

Este processo é vital para o projeto, porque pode ser que a equipe de gerenciamento não tenha controle sobre os membros da equipe selecionados para o projeto (lembram-se dos tipos de organizações onde ocorrem os projetos?). O “recrutamento” dos membros da equipe do projeto deve levar em consideração aquilo que foi planejado em termos de papéis, disponibilidade, capacidades, etc.

Processo: Desenvolver a equipe do projeto.

Este processo visa melhorar as competências e a interação dos membros da equipe para aprimorar o desempenho do projeto por meio de treinamentos, capacitações e trabalhos que busquem o aumento da sinergia da equipe, ou seja, trabalhos que busquem aprimorar os sentimentos de confiança e coesão.

Pode parecer menos importante, mas lembrem-se que lidar com pessoas já é difícil, se elas estiverem desmotivadas é ainda pior. Da mesma forma uma equipe motivada e coesa tende a gerar resultados maiores que o somatório dos trabalhos individuais de cada um.

Processo: Gerenciar a equipe do projeto.

Este último processo do gerenciamento de recursos humanos tem o objetivo de acompanhar o desempenho dos membros da equipe do projeto, fornecendo feedbacks, resolvendo problemas e gerenciando possíveis mudanças com intuito de melhorar o desempenho.

Este processo pode gerar grandes conflitos quando um projeto é realizado em uma organização matricial balanceada e os membros da equipe respondem ao chefe hierárquico e ao líder do projeto.

Finalizado os processos do gerenciamento de recursos humanos, faltam agora apenas os processos do gerenciamento de comunicações e de aquisições. Tem sido uma longa, mas com certeza, muito proveitosa viagem!!!

PMBOK – Áreas de Conhecimento – Gerenciamento de Riscos – Parte 2

Finalizando os processos do gerenciamento de riscos, vamos falar nesta postagem dos dois processos restantes desta importante área de conhecimento do gerenciamento de projetos.

Processo: Planejamento de respostas a risco.

Após identificar e fazer a análise qualitativa e quantitativa dos riscos é de extrema importância que a organização planeje as respostas que deverá ter para estes riscos. O processo de planejamento de respostas a risco tem a finalidade de desenvolver opções e determinar ações para aumentar as oportunidades e reduzir as ameaças aos objetivos do projeto. Essas ações podem ser antes do risco acontecer ou depois do risco ter se concretizado.

Existem três estratégias de respostas aos riscos que tem impactos negativos e três estratégias de respostas aos riscos que possuem impacto potencialmente positivos. Abaixo descrevemos cada uma delas.

Impactos Negativos

• Prevenir – É a estratégia que busca reduzir a probabilidade ou o impacto do risco a zero.

• Transferir – É a estratégia que faz a passagem do impacto negativo de uma ameaça para terceiros, assim como num seguro.

• Mitigar – É a estratégia que busca reduzir a probabilidade e/ou o impacto até um limite aceitável.

Impactos Positivos

• Explorar – É a estratégia que busca garantir que a oportunidade seja concretizada.

• Compartilhar – É a estratégia que faz a atribuição da propriedade para terceiros para que possam capturar melhor a oportunidade em benefício do projeto.

• Melhorar – É a estratégia que busca aumentar a probabilidade e/ou o impacto dos riscos positivos.

Observação interessante: O PMBOK não considera a estratégia de aceitação de risco, uma vez que não existe resposta quando o projeto apenas aceita que um determinado risco irá acontecer e que seu impacto será absorvido.

Processo: Monitoramento e controle dos riscos.

Este processo é responsável por monitorar e controlar os riscos por meio da identificação, análise e planejamento dos riscos novos que por ventura venham a aparecer no decorrer do andamento do projeto e do acompanhamento e reanálise dos riscos já identificados.

Este processo também faz uma revisão da execução das respostas aos riscos que tenham sido planejadas.

Já ultrapassamos mais da metade dos processos! Estão faltando agora poucas áreas de conhecimento. Vamos continuar a nossa viagem pelo mundo do gerenciamento de projetos, segundo o PMBOK? Então... Sigam-me os bons!!!

PMBOK – Áreas de Conhecimento – Gerenciamento de Riscos – Parte 1

Sendo uma área de conhecimento muito importante, o gerenciamento de riscos visa, basicamente, aumentar a probabilidade e o impacto de eventos positivos e diminuir a probabilidade e o impacto de eventos adversos. Risco positivo???? é isso mesmo???? Exatamente meus amigos. Para o PMBOK, assim como para outras metodologias/práticas, o risco pode ser positivo. A definição correta, na visão do PMBOK, é a seguinte: o risco é um evento ou condição incerta que, se ocorrer, terá um efeito positivo ou negativo sobre pelo menos um objetivo do projeto. Desta forma os processos desta área de conhecimento tratam de todos os aspectos relevantes em relação aos riscos que podem vir a acontecer em um projeto, seja ele positivo ou negativo.

Processo: Planejamento do gerenciamento de riscos.

Assim como nos outros processos de planejamento vistos até agora, o planejamento do gerenciamento de riscos tem a função de definir como abordar e executar as atividades de gerenciamento de riscos em um determinado projeto. Um planejamento cuidadoso e explícito aumenta a possibilidade de sucesso dos outros processos desta área de conhecimento.

O plano de gerenciamento de riscos define, entre outros itens, a metodologia a ser usada, as funções/responsabilidades, a orçamentação, as categorias de risco, a definição da escala de probabilidade e impacto dos riscos, a matriz de probabilidade e impacto, os formatos de relatórios, etc.

As figuras abaixo mostram exemplos de categorização de risco (identificadas em uma EAR – Estrutura analítica de riscos), escalas de impacto de um risco e a matriz de probabilidade e impacto respectivamente.

EAR - Estrutura Analítica de Riscos

Escala de Impacto

Processo: Identificação de riscos.

Este processo é responsável por determinar os riscos que podem afetar o projeto e documentar as suas características. O processo de identificação de riscos deve ser feito de forma iterativa e pode se valer de várias formas de informação, como por exemplo: informações históricas, técnica de brainstorming, método de delphi, entrevistas, etc.

A identificação de riscos leva naturalmente à análise qualitativa dos mesmos, apesar de que, alternativamente, pode levar diretamente à análise quantitativa, mas isso só seria aconselhável caso o universo dos riscos fosse bastante limitado.

Processo: Análise qualitativa de riscos.

Este processo permite priorizar quais riscos devem ser tratados inicialmente. É um método subjetivo de priorização de riscos identificados que avalia a prioridade com base na probabilidade de ocorrerem e seu impacto nos objetivos do projeto.

Processo: Análise quantitativa de riscos.

Este processo, por ser mais complicado de executar, deve ser feito com os riscos que foram priorizados pela análise qualitativa de riscos. Utiliza-se de técnicas como simulação de Monte Carlo e análise da árvore de decisão para avaliar a probabilidade de atingir objetivos específicos e identificar os riscos que exigem mais atenção e sua contribuição relativa para o risco total do projeto.

A simulação de Monte Carlo é feita por meio de softwares especializados e deve ser utilizado quando se tem um número maior de riscos e o efeito deles é cumulativo. Já a árvore de decisão deve ser utilizada quando se tem poucos riscos e se deseja tomar uma decisão específica.

Como já é de costume, para não deixarmos publicações muito extensas, daremos continuidade ao gerenciamento de riscos na próxima postagem...

Vamos juntos?

PMBOK – Áreas de Conhecimento – Gerenciamento da Qualidade

O gerenciamento da qualidade é formado pelos processos envolvidos na garantia de que o projeto irá satisfazer os objetivos para os quais foi realizado. É importante salientar que a qualidade não é vista apenas sob a ótica do produto ou serviço produzido pelo projeto. Ela também aborda a qualidade dos processos que fizeram com que o projeto chegasse a um final.

Processo: Planejamento da qualidade.

Este primeiro processo do gerenciamento da qualidade é responsável por identificar os padrões de qualidade relevantes para o projeto e determinar como satisfazê-los. Esta identificação pode ser feita por meio de uma ferramenta bastante famosa no meio dos projetos, o Benchmarking. Esta ferramenta permite comparar a sua organização com outras organizações e assim determinar quais serão os padrões de qualidade que deverão ser definidos e atendidos.

Não deixe de perceber uma grande máxima: qualidade é planejada, projetada e incorporada e não apenas inspecionada. O que isso quer dizer? Qualidade não é feita apenas no final da cadeia produtiva, quando o produto ou serviço é entregue, é algo que deve ser cuidada em toda as fases do ciclo de vida do projeto.

Processo: Realizar a garantia da qualidade.

Este processo busca a aplicação de atividades planejadas e sistemáticas para garantir que o projeto irá empregar todos os processos necessários para atender aos requisitos acordados. Como se pode observar, o foco aqui é nos processos, ou seja, não estamos verificando se o produto/serviço final está de acordo com os requisitos, na verdade o que se quer, neste processo é garantir que tudo será feito para que o produto ou serviço seja feito de acordo com o que foi requisitado.

Processo: Realizar o controle da qualidade.

Feito normalmente por amostragem, este processo tem o foco no produto ou serviço realizado pelo projeto. É responsável por monitorar os resultados específicos para determinar se estão de acordo com os padrões de qualidade. A equipe de controle de qualidade deve ter um conhecimento prático de controle estatístico da qualidade, especialmente de amostragem e probabilidade, para ajudar a avaliar as saídas do processo. Uma ferramenta muito utilizada é a técnica de Paretto ou, como também é conhecida, regra 80/20.

Continuaremos a nossa viagem pelos processos do gerenciamento de projetos na próxima postagem. Não desanimem!!!

PMBOK – Áreas de Conhecimento – Gerenciamento de Custos

Finalizando os componentes da tríplice restrição, nesta postagem estaremos tratando da área de conhecimento chamada de gerenciamento de custos. Esta área possui os processos necessários para que o projeto termine dentro do orçamento aprovado. É interessante notar que, para o PMBOK, o gerenciamento de custos trata principalmente dos custos dos recursos necessários para terminar as atividades, ou seja, dos custos referentes aos recursos alocados nas mesmas. Desta forma, se um empregado estiver de greve, por exemplo, o seu salário não conta como custo do projeto durante o período de greve, uma vez que neste período o empregado em questão não estava realmente alocado em uma determinada atividade do projeto.

Processo: Estimativa de custos.

Processo responsável pelo desenvolvimento de uma estimativa inicial, como o próprio nome do processo sugere, dos custos referentes aos recursos necessários para terminar cada atividade do cronograma. É importante lembrar que nesta estimativa deve ser levado em consideração as possíveis causas de variações nos custos, inclusive os riscos inerentes à atividade sendo estimada.

Assim como no gerenciamento do tempo, a estimativa de custos deve ser refinada com o caminhar do projeto. Também como na estimativa do prazo das atividades, a estimativa dos custos pode ser análoga ou paramétrica.

Processo: Orçamentação.

Como o próprio nome do processo já diz, é o responsável pela elaboração do orçamento do projeto. As estimativas de custos são preparadas antes das solicitações de orçamento detalhado e da autorização do trabalho. Este processo representa a agregação dos custos estimados de atividades ou pacotes de trabalho para estabelecer uma linha de base dos custos para a medição do desempenho do projeto.

Processo: Controle de custos.

O processo de controle do custo faz parte do controle integrado de mudanças, já discutido nos processos do gerenciamento integrado. O controle de custos do projeto inclui, entre outros objetivos, o controle dos fatores que criam mudanças nos custos, a monitoração das mudanças reais quando e conforme ocorram e o monitoramento do desempenho dos custos para detectar e compreender as variações em relação à linha de base. Este último objetivo é realizado por meio da análise do valor agregado.

A análise do valor agregado é uma técnica que utiliza a linha de base dos custos para avaliar o andamento do projeto e a extensão das variações de escopo, tempo e custo. Tem como base as seguintes medidas:

Valor Agregado (VA) → Custo orçado para o trabalho realmente terminado até o momento da análise. Avalia o escopo, ou seja, o quanto o projeto acha que o valor das atividades realizadas valem.
Valor Planejado (VP) → Custo orçado do trabalho agendado a ser terminado no momento que está sendo realizado a análise. Avalia o tempo, o que foi agendado para ser executado até um determinado momento.
Custo Real (CR) → Custo total incorrido na realização do trabalho até o momento da análise.

A partir das medidas descritas acima, pode-se analisar o andamento do projeto. Esta análise é feita por meio das seguintes medidas derivadas:

Variação de Custos (VC = VA – CR)
Variação de Prazos (V. Prazos = VA – VP)
Índice de Desempenho de Custos (IDC = VA/CR)
Índice de Desempenho dos Prazos (IDP = VA/VP)
Progresso Geral do Projeto (Prog. Geral = VA/Orçamento total)

O gráfico abaixo mostra um exemplo da análise do valor agregado plotada em duas dimensões. As siglas estão em inglês. Abaixo coloco a legenda para melhor identificação das medidas.



BCWP = VA
ACWP = CR
BCWS = VP
EAC = Estimativa no término (Previsão do cisto real ao final do projeto, com base no IDC).
VAC = Variação no término (Diferença entre o custo real ao final do projeto e o orçamento inicial).
BAC = Orçamento no término (Previsão inicial de custo total do projeto).

Continuaremos a nossa viagem pelos processos do gerenciamento de projetos na próxima postagem. Sigam-me os bons!!!

PMBOK – Áreas de Conhecimento – Gerenciamento do Tempo – Parte 2

Nesta postagem estaremos tratando e finalizando os processos do gerenciamento do tempo que não puderam ser tratados na postagem anterior. Vamos juntos?

Processo: Estimativa de duração da atividade.

Este processo determina o esforço necessário para terminar cada atividade do cronograma. Naturalmente, a estimativa de duração das atividades é elaborada de forma progressiva, com base na qualidade e disponibilidade dos dados. Existem três diferentes tipos de estimativas, a saber: a estimativa análoga, a estimativa paramétrica e a estimativa de três pontos.

A estimativa análoga é aquela estimativa baseada na experiência da pessoa que faz a estimativa. É uma percepção pessoal, normalmente baseada na duração real de uma atividade anterior com características semelhantes. É mais usada quando a quantidade de informações é limitada, como por exemplo, no início do projeto.

A estimativa paramétrica tem como base um histórico, não ficando presa a experiência pessoal. Um exemplo nítido é o uso da análise de pontos de função para determinar a produtividade a ser medida em homem-hora. Esta métrica permite estimar atividades correlatas, sempre se baseando no histórico existente na empresa.

A estimativa de três pontos usa uma média de três durações estimadas. Estas durações baseiam-se em uma estimativa otimista, uma pessimista e uma mais provável. A partir desta definição pode-se utilizar uma média ponderada, como no caso da estimativa utilizada por PERT, atribuindo os seguintes pesos: 1- otimista, 4 – mais provável e 1 – pessimista.

Processo: Desenvolvimento do cronograma.

Processo iterativo que determina as datas de início e término planejadas das atividades. Possui elaboração progressiva e continua durante todo o projeto. Um dos pontos altos deste processo está na análise de rede de cronograma. Rede de cronograma é uma técnica que emprega métodos analíticos que tem como objetivo calcular as datas de início e término mais cedo e mais tarde, além das datas de início e término agendadas para as atividades do projeto.

Os métodos mais utilizados na criação da rede de cronograma são: método do caminho crítico (CPM), nivelamento de recursos e análise PERT.

Não tenho a intenção de explanar tudo sobre esses métodos, pois teríamos que criar um novo blog só para isso, mas na figura abaixo apresento um diagrama de rede com CPM. O objetivo do CPM é determinar as folgas nos diversos caminhos da rede de atividades do projeto. A partir desta análise determina-se a duração mínima total do projeto. Veja que as atividades ligadas pela linha vermelha representam o caminho crítico, ou seja, se atrasarem a data final do projeto certamente estará comprometida.



Após a análise do caminho crítico utiliza-se a técnica do nivelamento de recursos para abordar situações de choque de recursos compartilhados. Este trabalho pode fazer com que o caminho crítico original mude.

Finalmente, a técnica de PERT permite, por meio de probabilidade, determinar a chance de um determinado cronograma terminar dentro do prazo estipulado.

Processo: Controle do cronograma.

Por último, porém não menos importante, o processo de controle do cronograma faz parte do controle integrado de mudanças, já discutido nos processos do gerenciamento integrado. Este processo é responsável por determinar o andamento atual do cronograma do projeto, controlar os fatores que criam mudanças no cronograma e gerenciar as mudanças conforme elas efetivamente ocorram.

Passados os processos do gerenciamento do tempo entraremos, na próxima postagem no gerenciamento dos custos. Não percam!!!!

PMBOK – Áreas de Conhecimento – Gerenciamento do Tempo – Parte 1

Nesta postagem estaremos descrevendo os processos da área de conhecimento chamada de gerenciamento do tempo. Assim como o gerenciamento do escopo, o gerenciamento do tempo faz parte da famosa tríplice restrição. Os processos desta área de conhecimento foram criados a fim de que seja possível chegar ao término do projeto no prazo correto. Em alguns projetos, especialmente os de menor escopo, os processos do gerenciamento do tempo acabam sendo executados como um único processo, que pode ser realizado por uma pessoa em pouco tempo.

Processo: Definição da atividade.

Este processo tem o objetivo de identificar e documentar o trabalho a ser realizado. Os pacotes de trabalho definidos quando da criação da EAP (vide postagem sobre o gerenciamento do escopo) são decompostos em componentes menores, chamados de atividades do cronograma. É importante lembrar que uma atividade é diferente de um pacote de trabalho. Enquanto este representa a menor unidade de entregáveis de uma EAP, as atividades mostram o que deve ser feito para que o pacote de trabalho possa ser entregue.

Processo: Sequenciamento de atividades.

As atividades, após terem sido definidas, devem ser sequenciadas usando as relações de precedência adequadas. Este processo busca, exatamente, colocar as atividades nas suas relações de precedência de forma a suportar o desenvolvimento de um cronograma do projeto realista e alcançável. A precedência pode ser normal, de antecipação ou de atraso e possui os seguintes tipos: término para início (TI – a iniciação da atividade sucessora depende do término da atividade predecessora), término para término (TT – o término da atividade sucessora depende do término da atividade predecessora), início para início (II – a iniciação da atividade sucessora depende da iniciação da atividade predecessora) e início para término (IT – o término da atividade sucessora depende da iniciação da atividade predecessora).

As dependências entre as atividades também podem ser classificadas como: obrigatórias (dependências inerentes à natureza do trabalho realizado – lógica rígida), arbitradas (estabelecidas com base no conhecimento das melhores práticas dentro da área de aplicação do projeto – lógica preferida ou fina) e externas (envolvem relacionamentos com atividades que não são da governança do projeto).

O sequenciamento de atividades podem ser representados por diagramas chamados como diagramas de rede. Os mais famosos são o MDP (método do diagrama de precedência) e o MDS (método do diagrama de setas). Essas representações não mostram o tipo de relação de precedência e nem a distribuição relativa das atividades no tempo, mas são muito úteis na definição do caminho crítico do projeto.

Processo: Estimativa de recursos da atividade.

Este processo é responsável por determinar os recursos a serem consumidos nas atividades. Quando se fala de recursos, estamos tratando de pessoas, equipamentos e materiais, ou seja, tudo o que for necessário para a execução da atividade. É importante lembrar que este processo tem uma relação muito estreita com o processo de estimativa de custos da área de conhecimento chamada de gerenciamento de custos, que ainda veremos mais para frente.

Para que não tenhamos postagens muito grandes, vamos dividir os processos do gerenciamento do tempo em duas partes. Na próxima postagem, estaremos falando dos processos que faltam desta importante área de conhecimento do PMBOK. Não deixem de acompanhar!!!!

PMBOK – Áreas de Conhecimento – Gerenciamento de Escopo

O gerenciamento de escopo é uma das principais áreas de conhecimento do PMBOK por fazer parte da tríplice restrição. Os processos desta área visam garantir que o projeto inclui todo o trabalho necessário, e apenas o trabalho necessário, para que seja concluído com sucesso. Vejamos a seguir os cinco processos que compõem esta importante área de conhecimento.

Processo: Planejamento do escopo.

Este processo faz parte do grupo de processos de planejamento e tem como objetivo principal descrever como a equipe irá executar os demais processos do gerenciamento de escopo. É importante salientar que, apesar do plano de gerenciamento do projeto (processo do gerenciamento de integração) definir o método do projeto como um todo, a definição do método do gerenciamento de escopo é feita dentro do processo de planejamento do escopo. Esta definição depende da área de atuação do projeto, por exemplo: um projeto da indústria automobilística deve se preocupar em realizar plantas do carro, maquetes, etc., já um projeto de software deverá conter casos de uso, protótipos, etc.

Processo: Definição do escopo.

Este processo também faz parte do grupo de planejamento e busca detalhar o escopo do projeto a partir da declaração de escopo preliminar. Necessidades, desejos e expectativas de todas as partes interessadas, e não apenas dos patrocinadores, são analisados e convertidos em requisitos. O nível de detalhe da declaração do escopo do projeto pode determinar a eficácia com que a equipe de gerenciamento de projetos poderá controlar o escopo global do projeto. Entre os tópicos que compõem a declaração de escopo detalhada, encontram-se: objetivos do projeto, descrição do escopo do produto, requisitos do projeto, limites, entregas, critérios de aceitação, restrições, premissas, riscos iniciais e especificações do projeto.

Processo: Criar EAP.

Um dos instrumentos mais famoso na construção de um projeto é a EAP. A estrutura analítica do projeto, como é conhecida em português (WBS – work breakdown structure, in english), é uma decomposição hierárquica orientada à entrega (produto) do trabalho a ser executado para atingir os objetivos do projeto. Esta estrutura deve ser tão detalhada quanto for necessária para identificar um pacote de trabalho, ou seja, identificar uma entrega que possa ser mensurada em termos de custo e cronograma de forma que seja fácil gerenciar. É importante determinar até que nível será detalhada a EAP pois, assim como a decomposição excessiva pode levar a um esforço grande de gerenciamento, a não decomposição pode dificultar a definição de custos e prazos.



A figura acima mostra um exemplo de EAP. Veja que o objetivo de uma EAP é organizar o escopo para se definir as atividades a serem executadas, porém as atividades não fazem parte da EAP, uma vez que a mesma, como dito anteriormente, é orientada a entrega. Existe uma discussão onde se prega que um projeto deva ter várias EAPs, cada uma focada em uma determinada visão (cliente, desenvolvedores, patrocinadores, etc). Estas várias formas de representar a EAP ajudam, apesar do trabalho, a alinhar as expectativas e melhorar o gerenciamento por parte do líder do projeto. Este é um assunto bastante polêmico e proponho que falemos dele mais adiante. Por enquanto vamos seguir com os nossos processos da área de gerenciamento de escopo.

Processo: Verificação do escopo.

Processo responsável por obter a aceitação formal das entregas pelas partes interessadas. É importante salientar que este processo não trata do atendimento aos requisitos de qualidade, uma vez que isso será realizado por outro processo. No âmbito do gerenciamento de escopo, o conceito de entrega difere do conceito de produto. Enquanto aquela representa o resultado de uma ou mais atividades que compõe um pacote de trabalho, este representa algo com valor para o cliente final. Os conceitos só se sobrepõem quando a entrega do pacote de trabalho é o produto final do projeto.

Processo: Controle do escopo.

Último, porém não menos importante processo área de gerenciamento do escopo, o controle do escopo faz parte do controle integrado de mudanças, já discutido nos processos do gerenciamento integrado. Este processo é responsável por identificar se a mudança no escopo é realmente válida e importante para o projeto. Este processo garante, também, que todas as solicitações e ações corretivas recomendadas sejam processadas pelo controle integrado de mudanças.

Apenas como curiosidade, as mudanças não controladas são frequentemente chamadas de scope creep, ou seja, perda de controle do escopo, ou, como traduz o PMBOK, aumento do escopo do projeto.

Passados os processos do gerenciamento de escopo entraremos, na próxima postagem no gerenciamento de tempo. Sigam-me os bons!!!!

PMBOK – Áreas de Conhecimento – Gerenciamento de Integração – Parte 3

Finalizando os processos da gerência de integração falaremos, nesta postagem, dos processos referentes aos grupos de controle e de encerramento.

Processo: Monitorar e controlar o trabalho do projeto.

Processo conhecido como “capataz do projeto”. Possui este apelido porque faz um comparativo entre o que foi planejado e o que foi realizado, ou seja, é o processo realizado para monitorar os processos dos demais grupos (iniciação, planejamento, execução e encerramento). É o responsável por coletar, medir e disseminar as informações sobre o desempenho e a avaliar as medições e as tendências para efetuar melhorias no processo. É importante salientar que o “capataz” não é o administrador, ou seja, não toma decisões, apenas comunica aos outros processos o que foi coletado, medido e avaliado.

Processo: Controle integrado de mudanças.

A única certeza que temos no ciclo de vida de um projeto é que teremos mudanças no decorrer de sua execução. As mudanças podem exigir estimativas de custos, sequência de atividades e datas do cronograma, recursos necessários e respostas a riscos novos ou revisados. Entende-se por mudança, dentro do PMBOK, as alterações na tríplice restrição (escopo, tempo e custo) e, de forma indireta, nos riscos. Isso é diferente de desvio! Um desvio refere-se a um ajuste no decorrer do projeto para que o mesmo volte aos trilhos, não sendo, necessariamente, resolvido por meio de uma mudança.

Cada solicitação de mudança deve ser rejeitada ou aprovada, automaticamente ou não, de forma que as mudanças aprovadas sejam incorporadas a uma linha de base revisada. Aqui surge um conceito que está sempre vinculado ao controle de mudanças nas mais diversas metodologias existentes no mercado: a existência de um sistema de gerenciamento de configuração. Este sistema permite o controle de versões e atualizações em qualquer item do projeto, identificando e documentando a linha de base, utilizada de forma primordial pelo processo de controle integrado de mudança, entre outros.

Processo: Encerrar o projeto.

Este processo tem como objetivos principais: coordenar as atividades necessárias para verificar e documentar as entregas do projeto, coordenar e interagir para formalizar a aceitação dessas entregas pelo cliente ou patrocinador e investigar e documentar as razões para as ações tomadas se um projeto for finalizado antes do seu término normal.

O encerramento do projeto é um processo que faz o encerramento administrativo, diferentemente de outro processo, que veremos mais adiante que trata do encerramento do contrato. Este foca mais na certificação de que um produto ou serviço contratado pelo projeto foi entregue de acordo com o que estava estabelecido.

Vale lembrar que o processo de encerrar o projeto também é executado em projetos com várias fases. Neste caso, o processo encerra a parte do escopo e as atividades associadas aplicáveis a uma determinada fase. Não se esqueçam que os grupos de processos não representam o ciclo de vida do projeto!!!!

A partir da próxima postagem falaremos dos processos da área de conhecimento “gerenciamento do escopo”. Não percam!!!

PMBOK – Áreas de Conhecimento – Gerenciamento de Integração – Parte 2

Dando continuidade aos processos do gerenciamento de integração, falaremos nesta postagem dos processos pertencentes aos grupos de planejamento e execução.

Processo: Desenvolver o plano de gerenciamento do projeto.

Este processo tem como objetivo principal desenvolver um plano que defina como será gerenciado o projeto, ou seja, o plano de gerenciamento de projetos deverá identificar quais dos 44 processos serão utilizados, quais ferramentas, como será a coordenação das atividades e o que será alvo de gerenciamento. Normalmente, o desenvolvimento do plano de gerenciamento de projetos é feito em dois tempos distintos: o primeiro seleciona e define a metodologia ou métodos a serem utilizados e o segundo consolida todos os planos no plano de gerenciamento do projeto.

Processo: Orientar e gerenciar a execução do projeto.

Também conhecido como “maestro do projeto”, este processo tem como objetivo orientar o desempenho das atividades planejadas no plano de gerenciamento do projeto e gerenciar as diversas interfaces técnicas e organizacionais que existem dentro do projeto. É interessante notar que, devido à existência deste processo, não há a necessidade de existir processos de execução para outras áreas de conhecimento como escopo, tempo, custo e risco, uma vez que os planos destes processos já estão consolidados no plano de gerenciamento do projeto, alvo do gerenciamento do processo de orientar e gerenciar a execução do projeto.

Continuaremos com os processos do gerenciamento de integração nas próximas postagens!! Vamos juntos!?