Tag Archives: COBIT

A TI é o foco? Cuidado ao responder.

2 Set

Não restam dúvidas que a área de tecnologia da informação (TI) é dinâmica e de vanguarda. E por isso, gostaria de compartilhar uma inquietude: se estamos envolvidos em uma área que olha sempre pra frente, que precisa a todo instante de recursos financeiros e ao mesmo tempo não gosta de ser identificada com uma área que consume muito pra pouco, então porque as estruturas de TI são semelhantes (para não dizer idênticas) a de outros setores, como contabilidade, RH, financeiro, etc.?

Antes de olharmos para metodologias e frameworks de governança, como ITIL e CoBiT, é necessário dizer qual será o posicionamento da TI frente às outras unidades de negócio da organização.

Basicamente: ela será descentralizada ou centralizada?

Isto é algo que realmente importa. Definir como a TI está situada dentro da empresa é fundamental. Acredito que muito se gasta com a TI por ela não ter o posicionamento correto. Ou seja, o modelo de outras unidades não serve para a TI!

Geralmente, os profissionais de TI e, especialmente, os Gerentes de Projetos, relacionam-se com pessoas de diversas áreas de conhecimento, principalmente por que precisamos entender o que e como fazem, para então propormos a melhor solução.

Isso traz a nossa área uma característica muito, mas muito especial: ela tem os profissionais que entendem como as unidades de negócio da empresa trabalham e como elas podem se integrar. A TI não é  fim nela mesmo. Engana-se o profissional que acha que isso é diferente.

Como consequência disso…Nós conhecemos os processos, melhor de que qualquer um! Isto é um fato!

Bom, mas o que isso tem haver com que coloco sobre a TI ser o foco?

Dizer que a TI é suporte parece ser simples, não é? E você com certeza já escutou isso em várias palestras, seminários, programas de auditório, entre outros meios…

Então, se somos meio, porque centralizamos a nossa gestão?

Onde quero chegar com essa conversa: os clientes conhecem do seu negócio e nós conhecemos os caminhos para que eles produzam de maneira mais eficaz e eficiente. Sendo assim, porque cada unidade de negócio não ter sua equipe de TI dedicada?!

Evidente que esta teoria não é minha. Muitos autores já propõe um modelo descentralizado de TI. Antes realmente achava essa ideia absurda, mas atualmente vejo que ela pode ser a saída.

Muitos Gerentes de Projetos tem o sonho de trabalhar em uma estrutura totalmente projetizada, acham que este é o caminho do sucesso. Mas sabemos as desvantagens que este tipo de estrutura pode trazer.

Estas mesmas desvantagens, como: perda de conhecimento, alto custo com equipes, dificuldade em se ter padrões e integrar soluções, desmotivação da equipe, etc. também acontecerão se a TI for descentralizada.

No entanto, pense comigo: se focamos nas unidades que tem prioridade de orçamento e projetos, consequentemente, a empresa, no sentido global, alcançará os resultados de maneira mais rápida e com maior qualidade. Com a TI não deve haver intermediários. A TI é meio, certo?! Não se pode ter uma estrutura totalmente funcional para a organização da TI.

Por mais que isso possa parecer subversivo, a ideia tem que ser discutida. Dê para cada unidade de negócio a sua equipe de TI. As reclamações que somos inoperantes vão diminuir sensivelmente. Indo além: os responsáveis pelas áreas que atualmente só demandam, passam a ser responsáveis pelo sucesso ou fracasso da equipe e do projeto. Para mim isso é fundamental!

E nós como ficamos?

Os gerentes de projetos, com o apoio de um PMO, será o elo entre a operação e a gestão de TI.

Por falar em gestão de TI, ela deve estar preocupada com:

  • Metodologias;
  • Padrões e padronização;
  • Integração;
  • Estabelecimento de políticas;
  • Acompanhamento de portfólio;
  • Suporte;
  • Busca por novas tecnologias, pesquisa…; e
  • Desenvolvimento humano.

Indo um pouco além, penso que nem sobre o investimento a Gestão de TI deverá ser responsável. A organização, neste caso, contará com um BELO de um PLANEJAMENTO ESTRATÉGICO que alinhe as unidades e direcione os recursos. Por isso, a organização será responsável pelo investimento e não um ou outro gestor.

Alerto para que isso não deva ser interpretado com um sonho, mas sim com uma premissa! Planejamento é obrigação e não acessório.

Para finalizar, recentemente li um artigo sobre “quais os três cargos de TI que devem sobreviver no futuro” e pensei: a TI descentralizada está cada vez mais próxima, ou melhor, já é uma realidade!

Se você tem uma opinião diferente ou concorda comigo, opine!!!

Abraços e até a próxima!

———————————————————————–

Sobre este assunto visite:

http://www.malima.com.br/article_read.asp?id=634

http://blog.opus-software.com.br/?p=170

http://olhardigital.uol.com.br/negocios/digital_news/noticias/quais_os_3_cargos_de_ti_que_devem_sobreviver_no_futuro

http://www.bain.com/bainweb/PDFs/cms/Public/Voce_tem_organizacao_de_ti_certa_Portuguese.pdf

http://www.tiespecialistas.com.br/2011/01/repensando-ti-na-estrutura-organizacional/

Imagem retirada de:

http://promoview.com.br/artigos-e-cronicas/131368-um-show-no-atendimento-por-paulo-araujo/

Comece seu projeto pelo inicio!

13 Jun

O título parece ser  redundante?   Só parece  …. e você vai compreender o porquê (se você continuar lendo, claro!)

Por incrível que pareça começar o projeto pelo seu inicio é muitas vezes uma tarefa árdua, e o pior… em diversas situações este fato (de iniciar pelo inicio) é totalmente negligenciado por nós e pelos patrocinadores do projeto. O agravante para nós é que aceitamos a “imposição” do “execute já!“, sem muitas vezes argumentar.

Por isso, o que quero mostrar a você neste post é a importância do pré-projeto. Espero que ao final da leitura você se sinta motivado a mobilizar os principais interessados do projeto para que deem a ênfase necessária a esta fase.

Veja algumas interessantes definições sobre os processos de iniciação, segundo o guia PMBOK v4:

  • “o uso do processo de iniciação no início de cada fase ajuda a manter o foco do projeto na necessidade empresarial para o qual o mesmo foi criado”
  • “os processos de iniciação podem ser executados por processos organizacionais, de programas ou portfólios externos ao escopo de controle do projeto.”

Veja o exemplo que é dado no guia:

  •  antes de iniciar um projeto, a necessidade de requisitos de alto nível pode ser documentada como parte de uma iniciativa organizacional maior.”

Só este exemplo contextualiza tudo que penso sobre a importância de um início bem realizado!

Mas apresento algumas atividades, que se você fizer, aumentará as chances de sucesso do projeto:

  • Primeiro: identificar staekholders tenha parceiros, gere comprometimento!
  • Segundo: mapear a origem da demanda do projeto – compreenda a necessidade do negócio e dê importância aos objetivos estratégicos.
  • Terceiro: realizar uma análise de viabilidade técnica para implantar o projeto – será se é possível fazer o que estão querendo? O custo de pesquisa não será maior do que o retorno do produto final?

Algo que sempre procuro realizar quando vou fazer um projeto, seja ele de qual tipo for, é questionar sobre como planejar alguma coisa, se:

Eu não sei o que querem,

Eu não sei quem são as pessoas que querem e para quê querem,

E se é possível ser feito.

A fase de iniciação e os processos que a suportam servem exatamente pra isso: levantar todas as informações necessárias para iniciar o projeto, ou seja, preparar o terreno para dar o passo seguinte –  planejamento do projeto.

Bom, e o Termo de Abertura do Projeto?

Para quem faz a prova de certificação PMP sabe que a coisa mais importante  – para efeitos de prova – do Termo de Abertura é a FORMALIZAÇÃO da indicação do Gerente de Projetos para o projeto. Até considero isso uma premissa. Mas o problema neste posicionamento é que, ao meu ver,  restringe o  valor ao Termo de Abertura do projeto.

Explico:

Novamente citando o guia, “o Termo de Abertura é o documento que formalmente autoriza um projeto ou uma fase e a documentação dos requisitos iniciais que satisfaçam as necessidades e expectativas das partes interessadas.”

Veja como o pré-projeto é importante!

Este termo, depois de preenchido e assinado, é que vai demonstrar todo o entendimento prévio daquilo que se consolidou da pesquisa inicial sobre o projeto.

Mas aí vem a pergunta: quem é o responsável por coletar todas as informações a serem consolidadas para se autorizar o projeto, já que não se tem, AINDA, um gerente de projetos formalizado para isso?

Antes, vamos combinar uma coisa: nem tudo é responsabilidade do gerente de projetos, ok?

Lembro que: só há gerente de projetos se houver projeto e eu estou falando de uma etapa que antecede ao projeto.

Para isso, nada mais justo que o patrocinador – apoiado por perfis estratégicos e técnicos – ou um comitê levante essas informações. Deste comitê não poderia sair o GP do projeto? Em minha opinião, sim!

O que pretendo mostrar a você é que o planejamento do projeto é fundamental, não restam dúvidas! Só que, tão fundamental quanto o planejamento é saber o que planejar.

Este é o principal objetivo do pré-projeto. É neste período que os objetivos principais são definidos. O planejamento deve estar voltado a viabilizar o alcance destes objetivos. O erro, geralmente cometido, está no fato do planejamento ser realizado “apenas” para viabilizar a execução do projeto.

O planejamento não é algo solto, ele tem origem… a fase de iniciação. É nesta fase que o planejamento, mesmo que indiretamente, se inicia.

Aí vem a questão do primeiro parágrafo: iniciar um projeto já com a indicação do gerente de projetos e a ele apenas fornecer as restrições de prazo e custo, além de uma visão bem mais ou menos do escopo é o correto?

Muitas vezes é assim que um projeto inicia. Não pelo começo, mas pelo meio ou pelo fim…

Talvez você já tenha vivido a experiência do “patrocinador” dizer: “execute! Você foi escolhido porque acreditamos em seu trabalho!”.

A questão não é acreditar ou não no trabalho de alguém, mas sim de possuirmos informações suficientes para atingir aos objetivos propostos.

Muitos projetos fracassam ou gastam mais tempo que o necessário com o planejamento porque não se tem as questões preliminares básicas respondidas.

Para finalizar, pense sempre e indague seus “admiradores” sobre as questões abaixo:

  • Existe um plano maior de onde originou a demanda para este projeto?
  • Por que querem (área, gerente, presidente, empresa) o projeto?
  • Quais os objetivos e metas que se pretendem alcançar com este projeto?
  • O que realmente pensam que deve ser produzido? Qual o resultado que esperam?
  • Há viabilidade técnica de se fazer o que querem?
  • Quem é a comunidade impactada pelo projeto? (nunca se esqueça disso)
  • Quem está interessado neste projeto? (nunca se esqueça disso)
  • Qual o resultado financeiro que se espera com o projeto? (muito importante!)

Respondidas essas perguntas, vamos iniciar o projeto. Bem-vinda a fase de planejamento!

Até a próxima!

Ei, Gerentes de Projetos e Analistas de Negócio! Qual o futuro de vocês?

19 Maio

Se no post “PMO. O que eu tenho haver com isso?” eu comentei que o tema “escritório de projetos” era algo que em determinadas situações eu não gostava de discutir, o assunto de hoje já me traz muita motivação.  Não sei se o ensejo para tanta motivação gira em torno das áreas de tecnologias (re)inventarem profissões a cada nova onda ou se o estímulo vem da minha própria necessidade de sobrevivência.

Enfim, o fato é que ao acompanhar o mercado de empregos, as necessidades de clientes, as demandas de cursos e das minhas próprias necessidades,  percebi o quanto as habilidades e técnicas de algumas profissões podem ser realizadas por um mesmo profissional.

Recentemente, recebi um e-mail, de uma importante autora americana ligada à área de gerenciamento de projetos, oferecendo cursos de aperfeiçoamento profissional. Entre os cursos estava um que me chamou a atenção, chamava-se: “Project Manager or Business Analyst: Who Am I?”

A oferta deste curso foi o estímulo necessário para compartilhar com você alguns pontos de vista a respeito “de quem sou eu”…

  • Um dado rápido: nas décadas de 80 e 90 havia uma figura muito importante chamada de Analista de Sistemas. Este profissional era o responsável por levantar e modelar sistemas baseados em regras de negócios. Havia também o programador, o cara que só codificava e era movido a escrever códigos. Logo, o mercado percebeu que muitos profissionais que modelavam sistemas também programavam e, até,  gostavam disso. Logo veio a demanda do PROGRAMALISTA. Se você é profissional de TI, com certeza irá se lembrar disso. Era O famoso dois em um a preço de um (que persiste até hoje).

E quanto a nós (gerentes de projetos) e aos Analistas de Negócio? Continuaremos a ser dois profissionais distintos ?

Será possível que um profissional desenvolva habilidades comuns aos dois perfis e se dê bem com isso?

(é verdade que são questões não muito fáceis de serem respondida…e eu não tenho a soberba de achar que tenho a resposta.)

Mas vou compartilhar com vocês o que pensei: como para os GP’s tem o guia PMBOK, os Analistas de Negócio tem o guia BABOK. Ambos são padrões reconhecidos internacionalmente que descrevem áreas de conhecimentos, atividades, tarefas e as habilidades necessárias para se tornarem profissionais de GP ou de Análise de Negócio.

A respeito, o Guia BABOK define a Análise de Negócios como sendo um “conjunto de atividades e técnicas utilizadas para servir como ligação entre as partes interessadas, no intuito de compreender a estrutura, políticas e operações de uma organização e para recomendar soluções que permitam a organização alcançar suas metas”.

Ainda neste Guia é citado que o Analista de Negócios é “o responsável por desvendar as verdadeiras necessidades das partes interessadas, não simplesmente seus desejos explícitos. Em muitos casos, o analista de negócios irá trabalhar também para facilitar a comunicação entre unidades organizacionais”.  Lembro que é atribuição básica do gerente de projetos a atividade de comunicação.

De acordo com Guia BABOK qualquer um pode ser Analista de Negócios, desde que execute as tarefas descritas no Guia.

Então calma! Este ponto é  importante: se qualquer um pode executar as tarefas do Analista, então o Gerente de Projetos não poderia desenvolver alguma atividade deste profissional?  Ou melhor, ele já não desenvolve algumas tarefas do escopo do analista?

Se formos simplistas e pragmáticos, colocaremos cada “macaco em seu galho”. Não misturaremos as coisas, certo?

Mas, FELIZMENTE, a área de TI não nos permite ser assim. Seria um retrocesso ir de encontro com a própria inovação que permeia a tecnologia da informação  e a demanda do mercado.

O que quero chamar atenção é que já existe (e isso é bem real) a necessidade do gerente de projetos saber mais do que “apenas” gerenciar projetos. É necessário que ele entenda do negócio, que construa a solução em conjunto com os demais analistas e engenheiros do projeto. O gerente de projetos moderno não se limita a planejar e monitorar o projeto, ele ajuda a entender os requisitos e as necessidades do negócio.

Sim! É neste ponto que vejo que as coisas podem se misturar.  O Gerente de Projetos e o Analista de Negócios podem ser a mesma pessoa. Até vejo que é bem mais fácil o Gerente de Projetos integrar as habilidades do Analista do que o contrário, mas de qualquer forma, os papéis podem se misturar…

Não resista!

As metodologias ágeis já sugerem isso. O gerente do projeto é mais um papel dentro da equipe e ele tem a responsabilidade de propor a melhor solução e a melhor maneira de fazer essa solução. A ideia do CHEFE da equipe, a meu ver, é ultrapassada.

Só para fechar, os profissionais que tiveram a visão de programar e fazer análise permaneceram no mercado por mais tempo. Os profissionais de gerenciamento de projetos e de análise de negócios que querem ter a empregabilidade em alta também devem abrir seus horizontes e agregar valor ao seu portfólio de conhecimentos e habilidades. E, para isso, nada como agregar competências!

É isso! Abraços e até a próxima!

PMO. O QUE EU TENHO HAVER COM ISSO?

3 Maio

O escritório de projetos (PMO – Project Management Office) é um tema recorrente em congressos, workshops, fóruns e por aí vai. Confesso que tenho até me afastado das discussões que envolvem este tema.

Explico: primeiro que é uma discussão sem fim sobre os reais benefícios que ele gera; segundo que cada empresa tem sua cultura e realidade e, portanto, não teremos modelos de escritório de projetos que sirvam para todas as organizações; e, por fim, nada é mais chato do que comparar um caso de “sucesso” com outro caso de “sucesso” que ninguém saiba exatamente do que se trata.

Oras, então porque falar sobre PMO neste post? Continue lendo que você vai entender!!

http://www.thepmoblotter.org/

imagem retirada de: http://www.thepmoblotter.org/

O engraçado, apesar de tudo, é que gosto muito do tema, exatamente por ele não ter uma fórmula pronta. Ou seja, é uma ideia em construção!

E o melhor: demoraremos muito tempo em ter um modelo único, pronto e consolidado, isso se conseguirmos ter algum.

O gerente de projetos, com certa experiência, sabe que para o projeto dar certo, ele dependerá muito do seu esforço pessoal e do comprometimento da equipe com o trabalho a ser desenvolvido. E quando o GP descobre isso, o PMO poderá ficar a ver navios. Se o escritório tem o objetivo de consolidar uma metodologia por toda a organização, o gerente de projetos pode ser seu algoz, pois ele irá fazer do jeito que ele acredita ser certo e não que alguém acredita que seja. Pode soar estranho… mas continue lendo.

O PMO quando posicionado em nível elevado na estrutura organizacional da empresa, pode muitas vezes ter uma visão muito macro das dificuldades setoriais em que os gerentes de projeto estão envolvidos. Já os gerentes de projetos, conhecem como poucos a cultura do seu setor/área dentro da organização. E isso torna a informação assimétrica em favor do gerente de projetos, principalmente, quando ele não faz parte do escritório de projetos.

  • Outra coisa que me questiono muito é quando um escritório de projetos é implantado sem o cuidado de se ter desenvolvido um plano estratégico para ele.
  • Qual a visão, missão, objetivos e metas deste escritório?

Todos na organização têm conhecimento sobre a visão e as metas de curto, médio e longo prazo deste escritório?  Lembro que muitas vezes nem mesmo o plano estratégico da empresa é conhecido por todos.

Ainda nesta linha, vejo muitos escritórios com o objeto de sua existência muito grandioso, o que tende a perder o foco no médio prazo. Em organizações que não tem cultura de gerenciamento de projetos é fácil tornar o PMO alvo de criticas por aqueles que o vêem como um ameaçador ou frustrar àqueles que o viam com solução para seus problemas.

E não é muito difícil adivinhar porque isso ocorre: não há entregas de curto prazo que mostrem os benefícios reais de se ter o escritório.

Volto a dizer: começar pequeno e bem planejado é fundamental.

Em 2009/2010 fiz um estudo sobre implantação de PMO’s no serviço público brasileiro e ao final dele constatei algo que meu orientador já me questionava: afinal pra que serve um PMO? Que benefícios ele traz? PRA QUÊ PRECISAMOS DISSO? Confesso que não consegui responder em sua totalidade estes questionamentos, algo que me frustrou.

Pra não dizer que sou pessimista quanto à implantação de um escritório de projetos, vou indicar quatro pontos que penso que não podem faltar quando se pensa em realizar um PMO:

  1. Defina os resultados de curtíssimo prazo (eu disse CURTÍSSIMO PRAZO) e que gere benefícios para toda organização. Dê visibilidade e atenda as expectativas iniciais.
  2. Reúna pessoas que compartilhem das propostas do gerenciamento de projetos. Envolva, principalmente, os gestores que se animam com a ideia!
  3. Desenvolva competências (e isso não pode ser feito depois da implantação). As competências preparam o ambiente para consolidar a infraestrutura do PMO quando ele for implantado. Você já terá pessoas que compartilham suas idéias! Ou seja, você terá seguidores!!!!!
  4. Não subestime o estado atual do processo em que as pessoas trabalham. Muitas vezes o inicio da maturidade do processo pode estar na consolidação dos processos que já são realizados há anos pela empresa.

Por fim, gostaria de dizer que acredito nos escritórios como disseminadores da cultura de gerenciamento de projetos, como estimuladores do processo de aprendizagem e de controle dos registros de lições aprendidas. Claro que vários outros objetivos podem ser contemplados, mas aí, uma nova discussão se inicia…

Abraços!!!

Dica Rápida: entregue produto e não documentação

1 Fev

Muito se fala que o PMBOK, RUP, COBIT são ótimos, no entanto, burocráticos. Será verdade isso? O fato é todos podem ser customizados conforme as necessidades de seu cliente. Para muitos, a burocracia é tomada como verdade necessária para esconder ou ocultar problemas maiores. Mas nenhum dos citados é burocrático ou gera “documentação desnecessária”.  Se gera algum tipo de documentação desnecessária é porque algo está errado. O importante é entregar produto/serviço e não documentação. O cliente espera ver o produto que ele comprou e de acordo com os requisitos que ele indicou. A documentação é importante mas não fundamental, que digam as metodologias Ágeis!

%d bloggers like this: