GPSUL Gestão de Projetos

Riscos Inevitáveis

2011-07-02T13:12:00.000-07:00

Por mais simples que seja, em nossos projetos sempre levantamos os principais riscos que podem ocorrer, seus gatilhos, impacto e probabilidade entre outros itens. Dentro do planejamento realizado é verificado se esses riscos serão, mitigados, aceitos ou evitados.

Porém existem certos problemas que apodemos esquecer de colocar em nossos projetos ou mesmo não temos como saber que poderia ocorrer.

Alguns desses riscos podem ocorrer quando os projetos englobam diferenças de culturas, diferentes regiões, cidades, países. Um exemplo dessa diferenças por exemplo ocorreu em um projeto em que participei, onde o cliente , que estava a fazer testes ligou informando que alguns dias dos testes iriam atrasar devido ao carnaval. O problema aí estava no planejamento do cronograma, realizado em uma determinada cidade que não possui tradição de carnaval e suas empresas costumam trabalhar neste período, enquanto o cliente localizava-se no Rio de Janeiro, onde a tradição do carnaval é influi diretamente.

Porém existem certos riscos que não conseguimos evitar, eles ocorrem, necessitam de atividades complementares , necessitam de tempo e aumentam o custo do projeto. São riscos como catástrofes naturais por exemplo.

Cinzas de um vulcão cancelando voos em continentes por milhares de quilômetros, enchentes devastando cidades, terremotos , tsunamis, etc. Lembro que li uma matéria na PM NetWork de Maio de 2011 uma matéria intitulada Shaken to the Core o qual comentava sobre um projeto de mudança na parte de TI do Wallmart no Chile, gerenciado pelo Sr. Michael Allen bem na época em que ocorreu o terremoto que abalou todo país. Para este tipo de problema é que temos a “gordura” representada no orçamento. Quando algo deste tipo ocorre, todo plano do projeto deve ser revisto, grande parte dos stakeholders são afetados.

No caso do terremoto no Chile ocasionou em 3 meses de atraso no projeto de TI, replanejamentos e reestruturação do projeto. Em casos assim não há como evitar o ocorrido, tampouco prever que isso ocorreria, deve-se aceitar os fatos e buscar a melhor alternativa para proceder o projeto e conseguir o seu sucesso.

Insper Connects – Da Gestão de Riscos em Projetos a... Resultados em Projetos

2011-03-23T08:42:00.000-07:00

Ajudando na divulgação de eventos da nsos área:

Insper Connects promove encontro para debate sobre Gestão de Riscos em Projetos.

No dia 29 de março, o Insper lança o Insper Connects, conjunto de eventos que tem o objetivo de promover network, debates e palestras sobre diversos temas de Negócios e Economia. No evento de estreia, “Da Gestão de Riscos em Projetos a... Resultados em Projetos”, o consultor Pedro C. Ribeiro, sócio-diretor da Stratech/TheProjectOffice, especializada em consultoria e treinamento em estratégia e gestão de projetos e riscos detalhará como a gestão de riscos pode ser um importante instrumento para alcançar os objetivos da organização.

Com moderação do professor e coordenador do Insper Guy Cliquet, o encontro é voltado para gerentes de projetos e profissionais envolvidos com gestão de risco, atuantes em todos os setores da economia.

O evento tem apoio do PMI, Project Management Institute, principal associação mundial de gerenciamento de projetos, que pede aos participantes para fazerem uma doação de mantimento não perecível ou brinquedo para crianças de 0 a 4 anos. As doações serão destinadas ao Instituto Segatto, que tem como missão promover a comunicação, o desenvolvimento humano e contribuir para o fortalecimento da educação.

As vagas são limitadas e os interessados devem fazer a inscrição pelo site www.insper.edu.br/connects.

Insper Connects – Da Gestão de Riscos em Projetos a... Resultados em Projetos

Data: 29/03 (terça-feira)

Horário: 19h

Local: Insper – Auditório Max Feffer – Rua Quatá, 300, Vila Olímpia, São Paulo – SP

Inscrição: www.insper.edu.br/connects

Entrada: doação de mantimento não perecível ou brinquedo para crianças de 0 a 4 anos ao Instituto Segatto.

Templates

2011-01-22T04:25:00.000-08:00

Li recentemente uma matéria sobre a utilização de templates para as documentações utilizados nos projetos. Quando estava iniciando em Gerenciamentos, utilizei muitos templates, para montar Termos de Abertura de projetos, planos de projetos, termo de encerramento, etc, e ainda hoje em dia utilizo. Porém os templates prontos são muito uteis quando já se formulou um processo, uma metodologia de desenvolvimento a ser seguido mantendo assim um padrão com as informações necessárias na sua organização.

Porém, quando ainda não se possui um processo definido e busca-se montar as documentações de projetos deve-se tomar muito cuidado com os templates a serem utilizados. Muitas vezes os templates possuem muitos termos que nem sempre necessitam ser utilizados. Por exemplo, para projetos grandes, necessitasse de uma grande quantidade de documentações, porém para projetos pequenos não necessariamente precisa-se todas as documentações.

Um certa ocasião montei um pequeno projeto de software com uns amigos. A primeira idéia era montar todo um planejamento documentando tudo sobre o projeto, criar um plano de risco, cronogramas, levantar todos os requisitos, apontamento de horas, etc. Porém o projeto ainda era pequeno, ainda estávamos levantando as informações, não havia ainda conhecimento profundo de negócio e conhecimento técnico por parte dos membros da equipe. A tentativa de criar uma documentação aprofundada sobre um projeto onde não se havia ainda uma metodologia ou conhecimentos necessários não deu certo.

Para este tipo de projeto buscamos documentações mais apropriadas, menos complexas, utilizamos scrum, que é uma metodologia em que as documentações são mais enxutas.

Já para projetos grandes temos que ter um organização maior, muitas pessoas formando projetos diferentes porém que possuem processos padronizados e nesse caso são essenciais para que tenhamos o controle e verificação de todas as documentações dos projetos, seja para o projeto em si ou para consultas de outros projetos.

Em resumo, a utilização dos templates deve ser vista para cada caso. Muita documentação pode tomar tempo do projeto em partes burocráticas e que dependendo do projeto pode tomar muito tempo.

Outro ponto importante é que para pessoas que estão iniciando como GPs, devem tomar cuidado para não se prender aos templates, eles ajudam a verificar as informações necessárias dos projetos, porém podem prender os GPs a ficarem presos em documentações e não olharem atentamente para o que realmente o projeto necessita. Cuidado para não entrar em rotinas desnecessárias com informações incompletas ou repetitivas no seu projeto.

Att.

Marcus Machado

Mudança de visão: Aceitar o Replanejamento durante o Projeto

2010-10-16T06:02:00.000-07:00

Olá, outro dia estava lendo uma reportagem sobre o replanejamento das atividades nos projetos e achei interessante a seguinte visão: todos comentam que uma coisa que se tem certeza em um projeto é de que haverão mudanças.

O que fazer com essas mudanças? Devemos Trata-las, evita-las, até que ponto devemos levantar informações e fazer estudos sobre os impactos destas mudanças?

Pelo PMBOK e as boas práticas do PMI é recomendado que na parte de planejamento de um projeto seja feito um estudo sobre as possíveis mudanças no projeto, o impactos dos riscos, os caminhos de tratamento dessas mudanças, mitigando , aceitando ou evitando as mudanças em relação ao escopo planejado. Este tipo de planejamento é muito bem aceito quando tratamos de projetos em que sabemos exatamente o que deve ser feito e como deve ser feito. São projetos em que se tem conhecimento claro do objetivo, requisitos e características.

Nesse tipo de projeto é mais fácil considerar as possíveis mudanças, antecipar e tratar suas consequências em busca de se manter o objetivo final.

Em alguns projetos, como projetos de software, por mais que seja feita uma analise preliminar do escopo, levantamento de requisitos, objetivos do projetos, normalmente ocorrem muitas mudanças desde da parte do contratante, tecnologias aplicadas, objetivos finais, etc. Esses tipos de projetos em que normalmente não há um conhecimento afundo do objetivo, conhecimento de negócio e conhecimento da tecnologia possuem um nível de mudanças muito maior, e normalmente para que essas mudanças não tragam uma diferença muito grande no final do projeto em relação a prazos e custos costumamos colocar uma margem grande “gordura” aumentando o custo total do projeto o que não agrada clientes , onde muitas vezes a própria empresa se responsabiliza com esses custos e acaba dando um tiro no pé.

Para projetos deste tipo o mais interessante seria trabalhar sabendo de que o escopo final pode mudar, sabendo que as mudanças vão aparecer e terão que ser tratadas. Nesse casso o mais interessante é quebrar a definição do escopo em blocos de atividades se for possível, e quebrar as entregas alinhando com o contratante que a forma de trabalho será essa.

Com entregar antecipadas de parte menores do projeto alguns problemas de tecnologia e visão de negócio podem ser antecipados e alguns problemas que ocorreriam várias etapas do projeto podem ser vistos antecipadamente desde que as lições aprendidas e a comunicação (relatórios e reuniões de acompanhamento) sejam feitas periodicamente.

Para quem trabalha com Scrum sabe que antecipando as entregas em partes menores (período das sprints) e trabalhando a mudança junto ao cliente se possível evitam que requisitos que no inicio pareciam importantes sejam criados (e depois nunca são usados pelos clientes) e que correções e modificações necessárias sejam verificadas o quanto antes , pois quanto mais tarde verificado no projeto mais caro sai a correção .

Tudo isso vai depender do seu projeto e do bom senso, pelo PMBOK a idéia é planejar da forma mais detalhada possível as informações para evitar problemas na execução, porém atualmente para determinados tipos de projetos sabemos que trabalhar com entregas menores, acompanhamentos constante e buscando resolver as mudanças o quanto antes diminui os impactos negativos e antecipa possíveis problemas de discordâncias de requisitos por parte dos contratantes.

Marcus Machado

Projecta Joinville 2010 - Habilidades e Ferramentas para o Gerenciamento de Projetos

2010-09-02T04:15:00.000-07:00

VII Seminário de Gerenciamento de Projetos

2010-08-08T18:36:00.000-07:00

Em Setembro teremos o VII Seminário de Gerenciamento de Projetos nos dias 21 a 24 no centro de eventos da PUCRS em Porto Alegre, o tema é "Inove para Gerenciar, Gerencie para Inovar".

Estamos apenas em Agosto mas já gostaria de ajudar na divulgação deste evento onde teremos a presença para este evento o Sr.GREGORY BALESTRERO, presidente do PMI.

Engenheiro industrial por formação, Balestrero possui extensa experiência na supervisão de relações administrativas, financeiras e internas em associações profissionais. Sob a sua liderança, o quadro de membros do PMI triplicou em número, chegando hoje a 500 mil filiados em 175 países. Mais de 275.000 profissionais conquistaram a certificação em Gerenciamento de Projetos e Programas na gestão dele. Palestrante principal dos eventos internacionais do CEO como os fóruns - Economist, Business Week e Forbes e a cúpula econômica Bo'ao, o Balestrero divulga mensagens fortes sobre a importância da Gestão de Projetos na obtenção de sucesso considerando o atual ambiente global de negócios. Em POA ele vai se reunir a 30 palestrantes que vão fomentar a aproximação e o intercâmbio entre os profissionais de gerenciamento de projetos e profissionais de demais áreas do conhecimento.

Para maiores informações acesso o site do evento:

http://www.pmirs.org.br/7seminario/

att.

Marcus Machado

Gerenciamento de Projetos e Equipe Comercial

2010-07-24T08:57:00.000-07:00

Alguma vez você já recebeu a noticia do comercial de alguma proposta recebida e aprovada com um prazo muito curto? Isso ocorre com a maioria da empresas. O grande problema se encontra na não integração entre o pessoal de equipe comercial, responsável pelas vendas e contratos e a equipe de PMO, responsável pelo portfólio de projetos.

A equipe comercial está sempre em busca de novas vendas, trabalham com metas audaciosas, recebem por comissão e muitas vezes levam aos atropelamentos. A empresa realmente tem que buscar vender cada vez mais, e normalmente o fato de assumir alguns riscos e correr atrás acelera o desenvolvimento da empresa e seus produtos. Porém tudo tem um limite.
Muitas vezes assumir propostas sem pensar nos riscos pode custar caro. Quando a empresa trabalha com gerenciamento de projetos e não possui um controle de portfólio onde a equipe comercial e os gerentes possuem um relacionamento comunicação aberta. Antes de fechar uma proposta devem ser verificados se existem recursos preparados e disponíveis, deve ser verificado se existem riscos altos e colocar esses riscos no contrato e inclusive compartilhando perdas e ganhos.

Como informa o PMBOK, o gerente não deve ser o responsável por montar os contratos, porém deve participar do mesmo, deve estar por dentro do que está sendo contratado, dos prazos, das entregas e participar de reuniões com o cliente se possível. Essa comunicação evita que contratos sejam fechados sem um estudo, pois o que poderia ser uma grande oportunidade pode virar uma grande dor de cabeça.

Proximos Eventos PMI-SC

2010-06-06T18:52:00.001-07:00

Proximos Eventos PMI-SC

2010-06-06T18:51:00.000-07:00

Trabalhando com as pessoas

2010-05-26T20:06:00.000-07:00

Olá,

Hoje venho a falar sobre pessoas, ou melhor, trabalhando com pessoas. Nos projetos em que participamos, independente da área em que estamos, um dos principais componentes são as pessoas.
No PMBOK temos uma área de conhecimento exclusiva para os recursos humanos, onde existe os processos de planejamento, contratação e mobilização, desenvolvimento dos recursos humanos e o gerenciamento.

Dentro deste contexto, as pessoas são tratadas como recursos, eu particularmente concordo com novas nomenclaturas em que as pessoas não são mais tratadas como "recursos" pois recursos normalmente servem para serem explorados. Se bem pensarmos as pessoas são mais que recursos, quando você está trabalhando com pessoas da sua organização deve pensar em muitos outros itens como o desenvolvimento, o treinamento, capacitação e visão sistemática em relação as pessoas e seu desenvolvimento em futuros projetos.
Muitas vezes me deparo com pessoas que reclamam do trabalho de gerente de projetos, um trabalho mal feito por gerentes ou por um escritório de projetos que leva a visão para os recursos de que o gerente de projetos na realidade é um cargo inútil que serve apenas para cobrar as tarefas e resultados, sem acompanhamento e preocupação com os membros das equipes, porém essa visão é construída encima de atos de gerentes que não possuem essa preocupação e normalmente focam no resultado imediato, dependendo desde o profissional como da cultura da empresa.

Encontrar pessoas bem capacitadas hoje em dia também não é fácil. Enquanto algumas pessoas brigam contra o desemprego a realidade para as empresas é e necessidade de encontrar pessoas capacitadas para o serviço.
Com base no desenvolvimento das pessoas eu sempre comento para meus alunos que eles devem aproveitar ao máximo as oportunidades que aparecem, algumas aparecem por golpe de sorte e outras nós mesmos temos que correr atrás e fazer as oportunidades. O que não podemos é ficar parados no tempo ou esperando que os seus pais, seus chefes, seus gerentes de projetos, seus coordenadores façam a diferença por você.

Em meio a este pensamento e como uma dica de um leitor do blog eu recomendo o programa de trainnes de 2010 da Ernst&Young, vocês podem conferir no site http://www.traineesey.com.br/ com 350 vagas abertas para estudantes e recém-formados nas áreas de auditoria externa, assessoria, transações corporativas e tributos, o processo seletivo acontece em nove cidades brasileiras (Belo Horizonte, Blumenau, Campinas, Curitiba, Porto Alegre, Recife, Rio de Janeiro, Salvador e São Paulo).

Como líder, GP, coordenador, ou qualquer outro cargo de liderança você deve pensar no desenvolvimento da sua equipe, como já diz o livro O Monge e o Executivo, uma das qualidades do líder é saber doar-se e pensar no outro, e desta forma consegue-se respeito e confiança.
Nos seus projetos como na sua vida você deve planejar o futuro, capacitação e atualização são essenciais para o seu desenvolvimento e da sua equipe, pode haver mais custo, pode levar mais tempo, porém se bem planejado, sistematicamente os benefícios virão.

att.
Marcus

Ferramentas de TI

2010-04-22T19:42:00.000-07:00

Olá,

Em várias atividades do PMBOK existe como ferramenta a ser utilizada as ferramentas de TI.
Na verdade para o gerente de projeto e para os participantes dos projetos, trabalhar sem suporte das ferramentas de TI hoje em dia é inviável. São softwares que vão desde desenvolver as idéias, requisitos, cronogramas, comunicação, testes, planilhas, orçamentos, apontamentos de horas etc.

A grande maioria das empresas utiliza grandes ferramentas como MsProject, Primavera, etc. Porém existem várias outras ferramentas que podem auxiliar aos GPS.

Entre elas destaco a ferramenta PERT CHART e WBS CHART PRO, são ferramentas para construção de diagrama pert , um diagrama de redes tipo nó onde é possível inserir as durações das atividades e traçar caminho crítico e construção de WBS, ambas possuem integração com MsProject. São ferramentas pagas, porém você pode utilizar a versão demo onde é possível utilizar as ferramentas com um número limitado de componentes.

Recentemente tive a oportunidade de teste um programa chamado Softteria (http://www.softteria.com.br/gerenciamento-projetos/), um programa nacional que possibilita ao GP cadastrar seus projetos, atividades, possui controle de custo, recursos, empresas, etc. Esse produto é on-line, podendo ser acessado de qualquer ponto em que haja uma rede de internet. A ferramenta é gratris para um usuário, e possui preços muitos atrativos para a utilização com um número grande de usuários. Existe também a possibilidade de atualizar informações em um blog do projeto, que se torna um painel oficial de informações do projeto, vale a pena conferir.

Mudando um pouco das ferramentas, na ultima publicação da revista PM Network há uma reportagem sobre a utilização de redes sociais e ferramentas da Internet como twitter, blogs, redes sociais na comunicação e troca de informações. É comentado também sobre o veto que algumas empresa possuem a ferramentas como messenger e skype. Por exemplo, vetar o skype pode ser um tipo de veto como cortar o telefone, a utilização é para o mesmo fim e deveria ser explorado pelas empresas, principalmente em projetos que possuem parte da equipe dispersa fisicamente em regiões diferentes.

Existe hoje uma vasta gama de ferramentas, open-source ou pagas, vale a pena testar as ferramentas e buscar a ideal para a sua necessidade.

att.
Marcus Machado

Definição do Escopo

2010-04-03T09:02:00.000-07:00

Este semana recebi um email de um aluno de admisitração pedindo para ajudar na definição do escopo de um projeto da construção uma guarita para uma empresa.
No momento que li o email fiquei pensando, não tenho conhecimento com projetos de construção civil, porém para um GP na teoria não é necessário ter conhecimento apronfundado sobre as atividades do projeto.
Com este pensamento resolvi responder o email para ajudar o estudante. O foco da minha resposta englobou as seguintes informações:

- na definição do escopo, primeiramente deve-se verificar os requisitos do projeto. O gerente de projetos deve ficar atento aos requisitos explicitos e aos requisitos implicitos, são aqueles requisitos que o cliente não fala nem documenta, porém se na entrega faltar tal item irá causar uma falta de satisfação na aceitação do resultado do projeto. Lembro-me do exemplo que um professor chamado Salvador comentava na aula de Gerenciamento de Projetos que fazia na UDESC: você vai em uma barzinho e pede uma cerveja. O garçom poderia trazer uma cerveja quente, empoirada, fechada. Porém ele sabe que o seu pedido , apesar de ser apenas cerveja, na realidade se refere a uma cerveja bem gelada, limpa, aberta. Neste caso as caracterírsticas da cerveja não foram explicadas , mas se faltassem iriam causar descontentamento ao cliente. Neste mesmo exemplo , uma satisfação maior ainda seria se o garçom trouxesse uma porção de amendoim, aperitivos, etc. Porém é arriscado em um projeto aumentar o seu escopo para satisfazer o cliente, tudo tem um limite, o cliente pode acostumar com esse tratamento e mesmo não sendo obrigatorio no projeto pode causar descontentamento caso não venha a ocorrer em novos projetos deste cliente.

- o não conhecimento sobre o assunto do escopo pelo GP: em projetos onde não se tem muito conhecimento das atividades necessárias, deve-se buscar o conhecimento de pessoas especializadas, consultores, recursos com conhecimentos técnicos do assunto, lições aprendidas, etc. No caso do email do estudante, deve-se verificar sobre outros projetos de construção, conversar com construtoras, verificar documentações como licença e alvará, etc.

- documentar o que vai ser feito e o que não vai ser feito: um dos problemas comuns em levantamento de escopo é deixar o escopo aberto e não definir itens que não fará parte do espoco, sendo que quando não é definido que não será feito o cliente pode achar que esses itens deveriam obrigatoriamente fazer parte do projeto. Isso gera desconforto, problemas com gold plating, atrasos e estouro de orçamento. lembre-se, documentar o mais claro possivel o que será feito e o que não será feito.

- nível de definição do escopo: ao levantar o espoco do projeto, as atividades devem ser descritas na WBS (EAP) onde deve-se cuidar até que nível você vai decompor as atividades, decompro em niveis altos pode causar problema com agrupamento de atividades em uma unica tarefa e prejudicam o controle do andamento do projeto, decompor demais também irá prejudicar seu projeto, onde o GP vai gastar muito tempo deconpondo e controlando o andamento das atividades.

Coloquei alguns itens, porém a definição junta um aglomerado de informações, conhecimentos e pessoas, não deve ser feito sozinho pelo GP, todos stakeholders devem ser envolvidos, as atividades e entregas devem ser claros para todos, pois o escopo é a base para o cronograma e para definição de outros intens do projeto (recursos, riscos, contratações, etc) mas esses itens ficam para posts futuros no blog!

att.
Marcus

Escopo e Cronograma para Projetos de TI

2010-03-10T18:13:00.000-08:00

Trabalho com desenvolvimento de software, e temos muitos casos com erros em cronogramas e contratações.

Muitos cronogramas estouram, milestones e entregas fora do prazo e muitas renegociações. Normal para qualquer projeto, como já diz a frase clássica: A única certeza que se tem em um projeto é que ele vai sofrer mudanças.
Porém por que projetos de software possuem tantos problemas? Grande parte dos projetos falham, atrasam, não são entregues, não possuem todos os requisitos contratados.

Ao verificar um novo projeto normalmente tem-se como base para verificar o escopo e em conseqüência o cronograma os seguintes itens:

- históricos de projetos parecidos
- consulta a pessoas especializadas (no caso de software consulta a analista de sistema e negócio)
- estudo e verificação por function points

Porém trata-se de uma combinação de fatores muito grande, onde desde uma mal verificação de requisitos pode acarretar em problema com cliente na verificação das necessidades intrínsecas e que no final acabam voltando com gold plating e que muitas vezes dão mais problema e trabalho do que o esperado e consomem as "gorduras" do projeto.

Outro item importante que causador de problemas é a contratação verificando apenas uma opnião única ou opinião de alguém sem muito conhecimento no assunto, por exemplo, um pequeno projeto que pode ser apenas a mudança de um layout de relatório que parece simples poder acarretar em uma trabalho gigantesco para quem vai modificar o código interno do programa, porém as horas são orçadas apenas pela visão do layout do relatório.

Como fazer para não errar?

Não existe formula mágica, deve-se cuidar com a contratação, o estudo do escopo, não pensar apenas no faturamento na hora pois quanto mais perto do fim do projeto maior é o custo do retrabalho, seu projeto vai precisar de acompanhamento e vai sofrer mudanças, o importante é estar sempre de olho nos indicadores. Muitas empresas adotam scrum ou outra forma de gerenciamento ágil, são boas formas de estar de olho no andamento e nos problemas que estão ocorrendo e as soluções possíveis com frequencia.
Não se esqueça também das lições aprendidas, fundamental para que novos projetos não cometam erros repetitivos. Um bom plano de projeto deveria trazer referência a documentos de lições aprendidas.

Perto de outros tipos de profissões como engenharia civil, medicina, agricultura , etc, a informática ainda é um bebe em crescimento, errando e buscando o caminho certo, busque sempre o bom sendo e não esqueça de verificar os riscos (positivos e negativos) e planejar os pulmões. Com uma boa gerencia a tendência é que mesmo com os erros os projetos tendem ao sucesso.

att.
Marcus

A small hole can sink a big ship...

2010-02-24T15:47:00.000-08:00

Olá,

Gostaria de compartilhar um pensamento que tive ao ler um trecho do livro "Você está louco! Uma vida Administrada de outra forma" do Autor Ricardo Semler.
Este ótimo livro, conta as dificuldades, inovações e situações vividas pelo autor em sua vida de empresário, onde assumiu a empresa do pai fazendo-a sair do buraco, crescer e adquirir outros nichos de mercado. Este livro não é exatamente sobre Gestão de Projetos, porém comenta da forma de administrar e queira ou não, um gerente de projetos pode ser assemelhado a um empreendedor sendo que muitas caracterís

ticas e habilidades das duas profissões são comuns entre si.

Em um trecho do livro, Semler comenta a frase que é titulo deste post: “A small hole can

sink a big ship...”, esta pequena frase me trouxe um pensamento sobre os riscos. Já comentei no post sobre riscos sobre a importância de classificar e aplicar o controle dos riscos, inserindo os valores verificados para mitigar, aceitar ou transferir e colocando nos prazos horas e tarefas de verificação dos riscos.

Um pequeno buraco pode não parecer uma grande ameaça, se for ignorado ele pode simplesmente deixar um pouco de água que não trará problema algum ao nosso navio, porém ele pode estar localizado em algum ponto deste navio em que um pouco de água seja suficiente para comprometer alguma função vital da navegação, pode não afundar a embarcação, porém pode causar desvios na sua rota. E no pior dos casos este buraco pode ir aumentando conforme a água entra e em uma questão de tempo pode afundar a sua embarcação.

As águas em que seu navio navega também podem influenciar... No caso do Semler, ele ariscou o crescimento de suas companhias comprando novas empresas em situações diversas, águas turbulentas, navios que levados pela correnteza e teve que corrigir sua rota. O risco está diretamente ligado ao quanto você está disposta a ariscar e a investir.

“Você está louco!” comenta um pouco de inovações, de transformações e riscos, recomendo a leitura deste livro para quem busca um crescimento administrativo e que tenha uma nova visão de gerenciamento, planejando, ariscando com o pé no chão, buscando inovações e oportunidades de crescimento, um pouco de loucura não faz mal a ninguém!

Marcus Machado

Blogs sobre Gestão de Projetos

2010-02-01T06:58:00.000-08:00

Olá,

A intenção que me levou a escrever este blog foi a de compartilhar experiências, notícias, materias sobre gestão de projetos. Agregando valor a esta idéia o Sr. Luiz de Paiva , autor do Blog Stakeholder ( http://www.ogerente.com/stakeholder ) criou um agregador de blogs sobre Gestão de Projetos.
Encontrei alguns blogs que ainda não conhecia e fico animado de o GPSUL estar neste grupo!

O link da página é: http://ogerente.com.br/rede/blogs-projetos

Aproveite a grande quantidade de material disponível e caso queira você pode sugerir um outro blog para ser inserido no site agregador.

att.
Marcus

Deslizes a serem evitados...

2010-01-18T17:52:00.001-08:00

Aos que trabalham como gerentes de projetos existe toda a carga e responsabilidade de efetuar um determinado trabalho ou serviço de forma a trazer o sucesso aos seus projetos. Dentro das características necessárias estão a liderança, comunicação, organização, orientação, acompanhamento, visão entre muitas habilidades que um GP necessita.
Com base em atitudes de gerentes de projetos busquei listar algumas que prejudicam o projeto e que um gerente de projetos pode realizar sem notar, e que muitas vezes levam a equipe a ter uma visão errada sobre o gerenciamento de projetos e um escritório de projetos.

- Qualquer problema pode me ligar que estarei na praia!
Umas das atitudes de um GP é sua ausencia enquanto a equipe trabalha duro. Normalmente no ciclo de vida de um projeto a parte de execução acaba sendo a mais custosa e onde ocorrem muitos tumultos. Nessa etapa normalmente é necessária a participação mais ampla, muitas vezes com horas extras e trabalho duro da equipe de projeto. O que alguns GPs esquecem é que eles fazem parte da equipe do projeto. Já vi situações em que a equipe estava trabalhando duro no fim de semana e o gerente de projetos estava presente para verificar a participação de todos, a verificação de necessidades da equipe e acompanhando gatilhos dos riscos listados. Porém já vi casos em que o projeto estava explodindo e o gerente de projetos passou rapidamente para ver se os recursos foram trabalhar e em seguida foi para praia dizendo que qualquer problema era so ligar no celular... e o pior, na segunda feira o GP levanta os problemas reportados pela equipe para a sua gerencia como se ele tivesse resolvido todos os mesmos.

Realmente o GP pode até não ter muita coisa a fazer na hora da correria da equipe de trabalho, porém moralmente sua presença demonstra mais preocuação perante a equipe, demonstra participação e tira a idéia de que o GP serve apenas para fazer cobrança. Lembre-se, você faz parte da equipe não apenas liberar tarefas e cobrar apontamentos!

- ... riscos e qualificação não foram contratados nesse projeto!
Nem sempre a negociação na hora de verificar o valor a se pago por um determinado projetos possui o valor de riscos e qualificação embutido. Normalmente o patrocinador do projeto não quer pagar esses valores e não quer pagar por riscos que podem vir a não ocorrerem. Apesar de existirem formas de contratação em que o valor do risco acaba sendo compartilhado entre contratado e contratante ainda não á muito comum esse tipo de contrato.
O GP e normalmente alguma equipe comercial deveriam negociar um pouco desse valor, mesmo que de forma intrinseca. O que ocorre normalmente é que os riscos podem até ser apresentados, porém não são verificados nos custos. O mesmo ocorre com treinamentos e qualificações de recursos. Como esse valor não é representado em tempo e custo no projeto e certamente venham a ocorrer e acabam por atrasar e ocasionar em perda de qualidade do projeto.

- temos poucos tempo, podemos diminuir os testes!
Muito comum e muito conhecido já pelos gerentes de projetos, porém o que parece que agora vai poupar tempo e dinheiro volta mais forte e mais custoso nos retrabalhos. Realmente se o trabalho é muito grande e o tempo é curto as atividades que aparentemente são menos importantes são cortadas. Nesse caso seria mais interessante negociar o prazo ou assumir um atrasado, dependendo muito da situação e do projeto. Porém testes são importantes, retrabalhos na fase final custam mais e diminui a qualidade do projeto.

- o projeto não teve sucesso, a culpa é da equipe...
O responsável por um projeto é o Gerente de Projetos, o projeto está indo mal? os recursos não estão ajudando? a contratação feita pela equipe comercial foi ousada? Existem muitos fatores que fazem um projeto não dar certo. Quem deve buscar as soluções e se antecipar aos problemas com um bom planejamento e fazer o melhor, desde a contratação, planejamaneto, execução, riscos, verificar capacidades e conhecimentos da equipe é o gerente de projetos e este deve mostrar a sua responsabilidade no sucesso ou no fracasso. Como um professor meu comentou uma vez de forma irônica, se o projeto teve sucesso todos os envolvidos são os responsáveis, se ele dá errado a culpa é do gerente de projetos .

Existem muitas atitudes que levam um gerente de projetos a ser mal visto, onde a função do gerente de projetos é visto apenas como mais uma pessoa a fazer cobranças, e não como um facilitador em busca do sucesso de todos, se preocupando com a equipe , com as atividades, riscos , qualificações , etc.
O gerente de projetos é o responsável pelo projeto e faz parte assim como sua equipe. Liderança não deve vir pela hierarquia do cargo e sim pelo respeito e participação , ajuda e responsabilidade.

Marcus Machado

Boas Festas!!!

2009-12-24T04:29:00.001-08:00

Esse foi um ano de conquistas e desafios! Porém com bastante esforço muitos projetos pessoais e organizacionais foram alcançados.
Que em 2010 tenhamos novos planos, novos desafios, sonhos e que nossos projetos se realizem...
... boas festas e um fim de ano de muita alegria!

Marcus Machado.

Gerenciando Projetos na Vida Pessoal

2009-12-12T07:46:00.000-08:00

Olá,

Você busca seus sonhos? Você corre atráz, planeja e controla os projetos da sua vida?

Pois bem, outro dia vi um material do Sr. Silvio Aurélio de Castro Wille comentando sobre os sonhos de nossas vidas e o gerenciamento do mesmo.
Somos muito aplicados nos projetos das nossas empresas,mas, e os projetos de nossas vidas? Segundo o sr. Silvio, os melhores gerentes de projetos são aqueles que gerenciam suas vidas e seus sonhos.
Um profissional, não somente de gerenciamento, deve buscar fazer o planejamento de seus sonhos, suas idéias e colocar em prática.

Como em uma organização, temos muitas idéias e sonhos, um verdadeiro portfólio de projetos de vida e que como em qualquer portfólio é necessário fazer as avaliações de importancia e Go-No-Go de desses projetos.

Um bom profissional sabe que deve ter equilibrio em sua vida, no trabalho, na familia, no lazer, nos estudos, nos amigos, etc. Normalmente o lado do trabalho sempre pende para o profissional, porém deve-ser sempre equilibrar todas as pontas da vida.

Utilizar as metodologias de gerenciamento de projetos para fazer o planejamento, controle de custos, prazo, escopo serve como ferramenta para a pessoa buscar suas conquistas.

Várias pessoas que conheço já me falaram que algumas coisas todos homem deveria fazer além de plantar uma árvore e escrever um livro, dentre as coisas todos comentam que todo mundo deveria se casar, construir uma casa e planejar uma grande viajem.

Estou no processo do casamento. o AP está a caminho. E realmente fica muito mais facil quando gerenciamos, sabemos exatamente o que queremos, quanto estamos dispostos a gastar, a verificar as contratações e fornecedores, etc. Se tudo der certo a viajem vem na lua de mel.

Mas não para por aí... com controle e planejamento nossos sonhos podem sempre continuar,
gerencie seus sonhos para correr atrás deles e não fique esperando que um dia vá acontecer... equilibre as atividades da sua vida e faça acontecer!

abraço!
Marcus

referência: http://www.projexpert.com.br

Comunicação

2009-11-26T15:38:00.000-08:00

Você tem um plano de comunicação adequado em seus projetos?

Uma das qualidades mais importantes do gerente de projetos é a comunicação. Não que o gerente de projetos precise ser um "vendedor" ou falar pelos cotovelos, mas este deve saber falar com as pessoas certas na forma correta, formal ou informal e captar que as mensagens são recebidas.
Mas o que quero comentar é sobre a comunicação em projetos, no plano de comunicação em si.
Planejar como serão feitas as comunicações, que informações são importantes para cada parte interessada, qual frequência buscar informações e acompanhamentos e quais ferramentas utilizar para a comunicação. Toda comunicação que venha a impactar no projeto deve passar pelo conhecimento do GP. Este por sua vez deve saber quais as partes interessadas devem receber essas informações. A linguagem para os gerentes e patrocinadores normalmente deve ser formal e com dados como gráficos e planilhas que tragam os resultados mais rapidamente, nada de informações muito técnicas .
Por outro lado para falar de informações de pacotes de trabalho com membros da execução do projeto e informações técnicas, não é necessário uma comunicação formal, porém lembrando que quando necessário é importante registar as informações mesmo que de forma informal por escrito. Manter os registros das informações e decisões tomadas é sempre importante.

A frequência de comunicação também é de extrema importância. Ficar encima da equipe a todo momento estressa a equipe e ocupa um tempo do GP que poderia ser utilizado em outras atividades, algumas atividades devem fica nas mãos de membros da equipe os quais se tem confiança.
Porém largar informações na equipe e não acompanhar os acontecimentos resulta em falta de controle. Tudo deve ser dentro do seu limite e em quantidades razoável sem omissões nem exageros.

Alguns projetos possuem equipes virtuais, participei de projetos em que metade da equipe ficou em uma cidade e metade em outra. Muitas ferramentas hoje em dia facilitam a troca de informações, ainda mais que tínhamos salas de tele e vídeo conferencia, msn, emails, telefone e o fuso horário era o mesmo nas duas regiões. Mesmo com todas essas ferramentas um encontro pessoal entre as equipes na hora de verificação de requisitos e na hora de verificar as entregas ajudou a formar uma força e vínculos mais fortes em busca do resultado final.

Planejar como a comunicação será feita e manter dados corretos para as pessoas certas em quantidades eficazes e registrar essas informações parece simples, mas deve ser tratado com cuidado, qualquer ruído pode prejudicar as atividades e causar futuros problemas em seu projeto.

att.
Marcus Machado

Papel do Analista de Negócio em GP!

2009-11-11T16:33:00.000-08:00

Na empresa em trabalho atualmente a equipe de PMO chama-se Gestão Estratégica, na realidade esta equipe é a junção do PMO contendo os gerentes de projetos e de uma equipe de Analistas de Negócios com grande experiência de negócio e relacionamento com clientes.

A idéia de buscar juntar o Analista de Negócio junto com os gerentes de projetos é de enriquecer o conhecimento de negócio, refinar requisitos, buscar verdadeiras causas de problemas e necessidades dos clientes.

Atualmente existe um instituto internacional de análise de negócio denominado The International Institute for Business Analysis – IIBA® demonstrando como o analista de negócios se comporta, as suas habilidades e como ajudar a melhorar os resultados dos projetos.

A análise de negócio visa completar as informações entre o levantamento de informações que irão formar o escopo do projeto. O analista de negócio deve buscar informações da causa dos problemas ou das verdadeiras necessidades do cliente através de ferramentas como brainstorming e diagramas de causa e efeito e entrevistas com clientes. Além de completar as informações de escopo e tarefas do projeto o analista de negócio ajuda a companhar o andamento do projeto atuando na execução e controle juntamente com o gerente de projetos. O analista de negócios também participa dos testes e aceites das entregas antes da entrega final ao cliente.

Em contra partida o gerente de projetos deve aproveitar o conhecimento de analise, modelagens, relacionamentos com clientes , conhecimento tecnológico, conhecimento de negócio, etc, do analista de negócio desde os requisitos, contratações, planejamentos e execução. Aplicando essa idéia a TI , o analista de negócio participa anteriormente ao analista de sistemas no levantamento e rastreabilidade dos requisitos, necessidade e características funcionais e não funcionais.

Como normalmente o PMO é um centro de custo onde é difícil negociar o custo das horas de gerenciamento de projetos para com os clientes, o analista de negócio alocado nesta equipe acaba por ser um custo (normalmente alto pois estes recursos são caros) o qual não agrega valor diretamente como mão de obra, os seus benefícios normalmente são verificados no decorrer dos projetos, onde os valores veem em ganhos de produtividade de projetos pois retrabalhos no período de requisitos custam em média 20% a mais, na fase de desenvolvimento normalmente custam de 40% a 60% a mais e nas fases de testes podem até passar de 100%.

Essa idéia talvez não se aplique a todo tipo de empresa, no caso de TI a utilização do analista de negócio na fase inicial traz um retorno significativo quanto ao aproveitamento dos projetos e o aceite final dos clientes. Pense nessa idéia!

Caso queira se aprofundar mais no assunto leia a matéria da revista Mundo PM ano 5 n° 28 – Ago/Set 2009 Analise de Negócio em Gerenciamento de Projetos.

Att.

Marcus Machado.

Projecta 2009 Joinville dia 04/12 - Tema: Gerenciamento de Mudança

2009-10-30T03:08:00.000-07:00

Em breve mais informações...

Portfólios, Programas e Projetos

2009-10-17T06:45:00.000-07:00

No ultimo encontro do PMI-SC que ocorreu dia 16/10/2009 , Projecta 2009 em Blumenau, foram apresentados várias palestras sobre o tema de Portfólio e Programas.

Apenas como forma introdutória, programas são conjuntos de projetos que buscam soluções em comum, com um determinado objetivo. Porfólios representa a carteira de projetos de uma organização.

Quando falamos de portifólio é valido lembrar que o gerenciamento do Portifólio faz parte da analise de negócio da empresa, das estratégias organizacionais.
O escritório de projetos deve acompanhar todas as etapas do projeto, desde o processo de venda até o final do projeto, sendo que não são todas oportunidades de novos projetos que devem entrar para a carteira de projetos, pois nem sempre o produto ou serviço faz parte da estratégia da empresa, ou pode-se não ter recursos disponíveis no momento para o novo projeto em questão entre outros tantos fatores que levam as escolhas dos novos projetos.

O acompanhamento do portfólio é outra etapa importante. Uma das paletras do Projecta apresentada pelo Sr. Omar Lorenzini Jr. da Senior Sistemas aprensentou um forma de controlar o andamento dos projetos, carga dos gerentes de projetos e da rentabilidade dos mesmos.
O sistema apesentado por ele demonstra que no período de dois anos e meio aproximadamente o PMO da empresa em que trabalha apresentou uma maturidade grande no controle dos seu projetos.
Munido de um Sofware de controle de portfolio que apresentam muitos dados os quais são aproveitados juntamente com gráficos , principalmente gráficos de bolhas, é possivel analisar os dados e buscar problemas como vendas agressivas (escopo mal analisado e preço fechado), problemas com recursos desde supergerentes a gerentes desanimados, projetos com atraso e índices de safizfação dos resultados.

Dentre esses itens apresentados um ponto importante foi demonstrado não apenas nesta palestra mas em outras também, foi o fato de delegar responsabilidade para membros da equipe a ponto de deixar nas mãos de pessoas confiáveis parte da estratégia e controle dos projetos.

Mesmo que a maioria das empresas sçao de TI, pode-se ver que cada empresa possui suas pecularidades e estratégias, e a troca de informações sobre o tema de portfólio demonstrou que todos temos muito a desenvolver e melhorar nossos controles para um melhor aproveitamento dos nossos projetos!

att.
Marcus Machado

A falta de planejamento...

2009-10-13T18:39:00.001-07:00

Olá,

Venho hoje comentar sobre o problema de falta de planejamento nos projetos.
Para quem trabalha em projetos pequenos , muitas vezes, parar para ficar avaliando um grande número de processos ou para planejar todos os processos de um projeto pode parecer um tempo perdido, onde é bem mais vantajoso verificar o que pode ser faturado, verificar recursos disponíveis e começar a executar o projeto.

Infelizmente isso ocorre e pode levar muitos desses projetos ao insucesso, onde a empresa acaba entrando numa rotina de executar projetos com base no faturamento rápido. Esse ciclo vicioso leva a projetos com um mal planejamento, pouco estudo de impactos em relação a outros projetos, um levantamento de problemas encima de sintomas e não das reais causas ou necessidades.

O planejamento é fundamental para projetos e programas. O planejamento engloba o escopo, estudo preciso de requisitos, de restrições, de efeitos em todos os envolvidos, inclusive em outros projetos concorrentes. A necessidade de buscar melhores soluções e não a solução mais rápida para faturar é que traz um sustentabilidade e muda o ciclo para virtuoso.

Planejar escopo, tempo, fazer orçamentos, verificar recursos, levantar os riscos e aplicar todo esse estudo com base nos efeitos futuros em temos de serviço e produtos e os efeitos positivos que trazem o sucesso para uma organização. Claro que não é necessário aplicar todos os processos de planejamento apresentados no PMBOK, porém verificar os reais problemas, buscar soluções reais e não apenas soluções pontuais, verificar se o custo que agora em um planejamento mais amplo parece ser muito alto acaba sendo um custo menor do que o custo de retrabalhos e replanejamento de projetos depois que o projeto já está em execução.

Um bom planejanento beneficia a organização, beneficia os custos, traz resultados futuros positivos e mostra resultados satizfatórios e não apenas pontuais.

Se você não dá muito valor a planejamento pense nisso, busque resultados verdadeiros e escopos completos e verdadeiros. Fazer o estudo dos custos e não exceder o limites faz parte, mas busque as verdadeiras soluções!

Abaixo segue uma propaganda com um pensamento em planejamento, a maioria já deve ter visto na TV, porém muito divertida!

abraços!
Marcus Machado

Projecta 2009 - Blumenau - SC dia 16/08/09

2009-10-07T12:07:00.000-07:00

No dia 16 de Outubro de 2009 ocorrerá em Blumenau o evento Projecta 2009 –

Blumenau - Gestão de Portfólio e Programas.

O evento irá abordar os diversos aspectos da Gestão de Portfólio e

Programas, com um foco prático e apresentação de cases de empresas

nacionais e internacionais.

EVENTO PROJECTA 2009
Gestão de Portfólio e Programas

Data: 16/10/2009

Horário: das 8h00 às 18h00

Local:

FURB - Universidade Regional de Blumenau
Auditório da Biblioteca Central - Campus I
Rua Antônio da Veiga, 140, Victor Konder
Blumenau / SC

Palestrantes Confirmados:

- Rui Wagner Ribeiro Sedor - Nokia/Siemens
- Omar Lorenzini Júnior - Senior Sistemas
- Nikolai Dimitrii Albuquerque - PMI SC
- Elton Soares - Grupo Dimensão
- Carlos Becker e Odisnei Galarraga - Software Process

Com distribuição
de 8 PDUs

Maiores informações:
Site: www.projecta2009.net.br
E-mail: pmivale@pmisc.org.br

Inscrições pelo site - www.projecta2009.net.br
Até o dia 08/10:
- R$170,00 para não-associados
- R$150,00 para Associados a outros Chapters do PMI
- R$130,00 para Estudantes
- R$120,00 para Associados ao PMI-SC

A partir do dia 09/10:
- R$200,00 para não-associados
- R$180,00 para Associados a outros Chapters do PMI
- R$160,00 para Estudantes
- R$150,00 para Associados ao PMI-SC

Aproveite o evento e traga toda sua família para curtir o

último final de semana da Oktoberfest de Blumenau!

Visão Sistemática em Projetos

2009-09-28T18:35:00.000-07:00

A um tempo eu estudei o livro de Teoria Geral de Sistemas do biólogo austríaco Ludwig Von Bertalanffy ( apresantado a mim por um grande professor Claudiomir Selner), um livro antigo (publicado entre 1950 e 1968) e que é apresentado em muitos cursos de informática e sistemas de informação.

Bertalanffy explica a teoria de sistemas, com um texto pesado e de literatura nada fácil onde pode-se encontrar informações de variação de sistemas conforme:

- Constituição : físicos ou concretos e abstratos ou conceituais.
- Natureza: fechado ou aberto.

Os sistemas o qual os processos de gestão de projetos do PMBOK representam são sistemas abertos, os quais trabalham com a troca de energia entre o meio externo e o interno, sendo adaptativos, buscando se reajustar ao meio em que estão envolvidos.

Projetos em si são sistemas abertos, como um sistema aberto o projeto assim como a organização possui funções primarias:

- eles nascem, evoluem, e morrem, no caso dos projetos eles tem um fim, seja positivo ou negativos.

- possuem total influência com o meio externo, a troca de energia (informações e ações) com outros sistemas (organizações, stakeholders, empresas, outros projetos, etc).

- possuem a perspectiva de controle com feedbacks de informações e ações em pontos de alavancagem estratégicos.

O conjunto de conhecimentos apresentado pelo PMBOK divide-se em termos de aprendizado em 9 áreas de conhecimento: integração, escopo, tempo, custo, qualidade, recursos humanos, comunicação, risco e aquisições. Cada item pode ser estudado e verificado separadamente, porém jutamente com os 5 processos: iniciação, planejamento, execução, momitoramento/controle e encerramento onde esses itens se misturam e uma mudança afeta todo o sistema ,que afeta outros sistemas externos, afeta pessoas, afeta economias, afeta estratégias e futuros de corporações.

A abordagem sistemas trabalha com fatores que em projetos são muito importantes:

-> dividir para conquistar: a divisão das atividades, das estapadas, distribuições de responsabilidades, etapas planejadas, são formas sistemicas para alcançar o todo.

-> Olhar o todo: ao mesmo tempo que a divisão é necessária não pode-se esquecer do olhar para o todo, ter uma visão ampla do sistema e identificar todas as partes afetadas direta ou indiretamente no sistema.

-> verificar os detalhes: os detalhes fazem a diferença, podem aparecer durante o andamento do projeto (desenvolvimento do sistema) mas deve ser sempre verificado em busca de melhor solução. Sempre lembro do exemplo na corrida espacial dos anos 70 e 80 a história do desenvolvimento da "caneta espacial" dos americanos e o uso do lápis pelos Russos.

-> analogias: na teoria geral de sistemas a analogia refere-se ao reuso de métodos que deram resultados positivos para soluções e desenvolvimentos evitando gastos desnecessários, em projetos isso se reflete em lições aprendidas e demais fatores ambientais e ativos organizacionais da empresa.

Para quem conhece o guia do PMBOK sabe que nos processos e conjunto de conhecimentos apresentados existem as entradas, as ferramentas e as saídas de cada processo, e que esses itens na verdade são um conjunto de troca de informações, sinergia, feedbacks, uma relação entre vários subsistemas e as partes de um todo.

Pode-se dividir o projeto em sistemas de nível macro, onde cada projeto se relaciona com outros projetos, programas e fazem parte de um sistema maior, o portfólio da empresa. Também existe o sistema mais amplo que é o ciclo de vida do produto, diferente do ciclo de vida do projeto.
Em níveis médios pode-se relacionar sistemas como partes do projeto, processos e etapas. Relação de um projetos com patrocinadores, gerencias, equipes envolvidas, clientes, etc.
Em níveis mais específicos pode-se relacionar controles no sistema, controle de qualidade, desempenho, comunicação, documentos e atualizações dos mesmos, controle dos risos e acompanhamento. O controle de causa e efeito também é aplicado neste nível do sistema.

A teoria de sistemas é antiga e se aplica tanto a pessoas, organizações como a projetos, em vários níveis, em vários pontos de alavancagem e nas consequencias que um sistema sobre em relação a troca de energia e a alimentação cíclica e retroativa entre projetos e processos dos projetos.

De forma implícita um Gerente de Projetos acaba estudando e aplicando teoria de sistemas, pois todos estamos envolvidos em vários níveis e tipos de sistemas, quanto melhor entendermos a forma sistemática que as ações trazem, melhor preparados estaremos para os resultados e ações resultantes.

Essa é apenas um introdução superficial a teoria geral de sistemas e a relação com Gestão de Projetos. Pretendo em futuros posts entrar com mais detalhes e explorar esse conhecimento aplicado a projetos.

Um abraços!
Marcus Machado