É óbvio também, que algumas tecnologias ou metodologias de gestão de projeto aumentam exponencialmente as chances de sucesso. Ainda que não se absorvam totalmente as
ferramentas ou metodologias de gestão de projetos, é possível organizarem-se e obterem-se resultados, logo na primeira tentativa (JOBSTRAIBIZER, 2008).
As ferramentas objetivam a automatização dos procedimentos, mas também são bem empregadas para fidelização, interação e organização das informações para os clientes (JOBSTRAIBIZER, 2008).
A ferramenta opcional apresentada, UML, foi considerada possibilidade da maioria dos autores, no caso dos sistemas de informação e/ou computacionais, terem conhecimento mais desta ferramenta do que as próprias ferramentas de gestão de projetos (Diagrama de Gannt, Diagrama de rede e Estruturas hierárquicas). O objetivo é a facilitação por serem os autores mais familiarizados com esta ferramentas.
Larman (2004, p. 580, 581) cita que metodologias e ferramentas orientadas a objetos têm sido frequentemente promovidas, porém é uma surpresa entre os profissionais da área.
5.3 PROPOSTAS PARA TRABALHO FUTURO
Este trabalho teve a visão de identificar a falta da ciência de gestão de projetos nos trabalhos de conclusão de curso da área tecnológica, para atender a um pequeno público voltado para formação do ensino superior, porém, com algumas pequenas adaptações.
Inadequado seria esquecer a viabilização destes tipos de concepção com curso de diferentes áreas como o de engenharia ambiental, por exemplo, e até mesmo área técnica, resguardando as proporções e ainda a finalidade.
Dentre as propostas de trabalhos futuros é interessante pensar na possibilidade de aplicar este pensamento aqui documentado nos cursos de tecnologias e observar os resultados.
Registra-se, porém, que ao observar os resultados devem serem considerados o lado do concludente do curso, a ótica da banca examinadora e ainda, se possível, também apresentando ou convidando os segmentos de mercado para onde forem direcionados os trabalhos analisados, para que estes possam opinar sobre a tecnologia dentro do documento apresentado.
6. BIBLIOGRAFIA
AVELLAR & DUARTE Consultoria e Design. Anotações sobre gestão de projetos de web e portais. Disponível em: <http://www.avellareduarte.com.br/projeto/planejamento/
planejamento4/planejamento41.htm>. Acesso em 01 ago. 2008.
BARSA. Guia das Profissões. Rio de Janeiro: Barsa Planeta, 2005.
BORREGO FILHO, Luiz Fernando. et al.. Análise e modelagem para automação de processos de gerenciamento de projetos. In: Simpósio Internacional de Matemática e Morfologia (International Symposium on Mathematical Morphology -ISMM). São José dos Campos, SP: 2002. Disponível em: <http://hermes2.dpi.inpe.br:1905/col/lac.inpe.br/lucio /2002/11.08.15.13/doc/BorregoFilhoLF.pdf>. Acesso em 29 nov. 2007.
BRUNO, Fernanda Carina Magalhães; GAETA, Sérgio Bueno. Implementação de sistemas ERP em pequenas empresas no Brasil. Disponível em: <http://www.sbg.com.br/artigos/
download/implementacao_erp.pdf>. Acesso em 24 out. 2007.
FONSECA, Sérgio Ulisses Lage da. Benefícios da adoção do modelo PMBOK no desenvolvimento e implantação do projeto de tecnologia da informação de um operador logístico: estudo de caso da World Cargo. 2006. 128 f. Tese (Mestrado em Gestão de Negócios) – Universidade Católica de Santos, Santos.
CAIGAWA, Sidney Maçazzo et al.. Algumas considerações estratégicas sobre a utilização do marketing de relacionamento pelas empresas. Uma pesquisa exploratória junto a um banco brasileiro. VII Seminários em Administração, Agosto de 2004. USP
GOMI, Edson Satoshi. Gestão de Projetos. Departamento de Engenharia de Computação e Sistemas Digitais. Escola Politécnica da USP. PSI-2222 – Práticas de Eletricidade e
Eletrônica II (in: Nota de aula: Laboratório de Processamento de Sinais, Departamento de Engenharia de Sistemas Eletrônicos, Escola Politécnica) Universidade de São Paulo. 11 fls.
2003, Disponível em: <http://www.lps.usp.br/lps/arquivos/conteudo/grad/dwnld/Apostila Gestao.pdf>. Acesso em 29 nov. 2007.
GUEDES, Gilianes T. A.. UML: Uma Abordagem Prática, São Paulo. Novatec Editora, 2004.
HESS, Pablo. Precisa ser preciso. Linux Magazine, São Paulo, p. 33, nº 45, ago. 2008.
JOBSTRAIBIZER, Flávia. Bom projeto, bom gerenciamento... bons resultados. Linux Magazine, São Paulo, p. 34-38, nº 45, ago. 2008.
KOLLVEIT, Bjon Jonh et al.. Perspective on Project management. International Journal of Project Management, Volume 25, Issue 1, January 2007, Pages 3-9 Received 7 July 2005;
received in revised form 14 October 2005; accepted 13 December 2005
LARMAN, Craig. Utilizando UML e padrões: Uma introdução à análise e ao projeto orientado a objetos e ao Processo Unificado; Tradução Luiz augusto Meirrelles Salgado e João Tortello. 2ª Ed – Porto Alegre. Bookman, 2004.
LEWIS, James P.. Como Gerenciar projetos com eficácia. Rio de Janeiro: Campus, 2000
Manual de Referência do MySQL 4.1: 1997-2006, disponível na web em 2006-12-04 (revisão:
104). Disponível em: <http://downloads.mysql.com/docs/refman-4.1-pt.pdf>. Acesso em 20 nov. 2006.
MENEZES, Luís César de Moura. Gestão de projetos. 2ª ed. São Paulo; Atlas, 2003.
MENTA, Michael. Uso da WBS em projetos de comunicação. Blog da Folha de São Paulo, maio de 2008. disponível em: <http://insigthsecomunicacao.blogspot.com/search/label/EAP>.
PELLEGRINELLI, Sergio. et al.. The importance of context in programme management: Na empirical review of programme practices. International Journal of Project Management, Volume 25, Issue 1, January 2007, Pages 41-55 Received 22 November 2005; received in revised form 10 February 2006; accepted 15 June 2006
PINHEIRO. Andréia Azevedo. et al.. Metodologia para gerenciar projetos de pesquisa e desenvolvimento com foco em produtos: uma proposta. Revista de administração Pública v.
40, n. 3, Rio de Janeiro, Maio/Jun. 2006, Disponível em: <http://www.scielo.br/scielo.php?
script=sci_arttext&pid=S0034-76122006000300007&lng=&nrm=iso&tlng=>. Acesso em 15 dez. 07.
PHILLIPS, Joseph. Gerência de projetos de tecnologia da informação. Rio de Janeiro:
Elsevier, 2003.
PRADO, Darci Santos do. Gerência de projetos em tecnologia da informação. Belo Horizonte: Editora de Desenvolvimento Gerencial, 1999.
_______. Gerência de projetos nas organizações. Belo Horizonte. Editora de Desenvolvimento Gerencial, 2003.
PROJECT MANAGEMENT INSTITUTE. A Guide to the Project Management Body of Knowledge 2004 – 3th Edition, (Guide PMBOK 2004 – Um Guia do Conjunto de
Conhecimentos em Gerenciamento de Projetos – 3 Edição). USA (New York): Project Management Institute (PMI), 2004. 403 p.
RAMOS, Ricardo Argenton. Treinamento prático em UML – São Paulo Editora: Digerati Books, 2006.
SANTOS, Luis Augusto et al.. Aplicação da Técnica de Estrutura Analítica de Projeto para o sub-projeto do Catálogo de Sites da Biblioteca Virtual em Saúde - Enfermagem. Revista Brasileira de Enfermagem (REBEn): 2007 Nov-Dez; n. 60(6): p. 716-20. Disponível em:
<http://www.scielo.brpdfrebenv60n617.pdf>. Acesso em jul. 2008.
VALERIANO, Dalton L.. Gerenciamento Estratégico e Administração por Projetos. São Paulo: Makoron Books, 2001.
VASCONCELOS, Paulo Fernado. EPBE (Erickson-Penker Business Extensions) – in: Blog Finito, Disponível em: <http://finito-log.blogspot.com/2007/10/epbe-introduo.html>. Acesso em 25 jun. 2008.
APÊNDICE A – Questionamentos procurados nos trabalhos de conclusão de curso
ANEXO A - Visão geral da Metodologia de Gestão de Projetos
Convém ressaltar que o gerente de projetos por si só, não garante o sucesso de nenhum projeto, porém, sua competência e habilidade para aplicar boas técnicas induzem a resultados mais sólidos. Pode-se afirmar que as habilidades do gerente são inerentes não só à reunião de conhecimentos adquiridos com o tempo, ou seja, à experiência empírica do profissional, mas também à capacidade para utilizar a metodologia e as ferramentas da gestão de gerência de projeto.
Sobre as áreas de conhecimento de gerência de projeto o PMBOK (2000), define as seguintes áreas: (i) Gerência de integração do projeto; (ii) Gerenciamento do escopo do projeto; (iii) Gerenciamento dos tempos do projeto; (iv) Gerenciamento dos custos do projeto;
(v) Gerenciamento da qualidade do projeto; (vi) Gerenciamento de recursos humanos do projeto; (vii) Gerenciamento das comunicações do projeto; (viii) Gerenciamento dos riscos do projeto; (ix) e, Gerenciamento de aquisições do projeto.
Figura: Áreas de conhecimento (fonte: ROCHA, 2003)
Início de um projeto
Iniciar um projeto, nada mais é do que o reconhecimento oficial da necessidade de ser implementado um produto ou tecnologia nova ou aprimoramento do existente, por imposição legal ou do mercado consumidor. De acordo com o PMBOK (2000 apud ROCHA, 2003), os projetos acontecem como resultados de uma dentre as necessidades ou demandas: (i) demanda
Escopo Tempo
Integração
Custo Qualidade RH
Comunicação Risco Aquisição
do mercado; (ii) necessidade empresarial; (iii) avanço tecnológico; (iv) exigência legal; e/ou (v) necessidade social.
Este processo de reconhecimento faz parte da área do conhecimento “ESCOPO”, onde são definidas as metas do projeto. Rocha (2003) afirma que nesta fase, devemos seguir a regra
“SMART” (Specifc – especifico, Measurable – mensurável, Accurate – exata, Realistc and tangible – realistas e tangíveis, Time bound – limite do tempo), ou seja, definir metas de forma clara, possíveis de serem medidas, precisas em conformidade e centradas com as necessidades e por final com prazos, mas prazos realizáveis.
Planejamento do projeto
A principal razão pela escassez de literatura sobre controle do planejamento é a dificuldade em definir uma linha de base no monitoramento do progresso durante a fase de planejamento (ROCHA, 2003). No entanto, é notório que em qualquer que seja o projeto, desde uma simples receita culinária até mesmo projetos para colocar uma nave no espaço, deve existir sempre um plano que conduza o processo, ou estratégia.
É na fase do planejamento todos os esforços devem ser direcionados para atingir os objetivos do projeto referentes à qualidade, funcionalidade, confiabilidade, cronograma e custo. Entre as etapas do planejamento, Rocha (2003) cita:
• A fase inicial do planejamento também deve ser aprovada pelos stakeholders8, que caberá o compromisso entre o projeto, a empresa e os indivíduos que serão envolvidos ou afetados diretamente ou indiretamente pelo projeto.
• O “ESCOPO”, também faz parte do planejamento, pois esta etapa vai definir todo o planejamento. Nessa fase são relacionadas todas as atividades das áreas do projeto.
• O “TEMPO” é um dos fatores de sucesso para garantir que as tarefas sejam concluídas nos prazos. Normalmente para esta fase, são utilizadas várias ferramentas gráficas, para determinarem o seqüenciamento do projeto, suas atividades e sub- atividades.
• O “CUSTO” durante a fase de planejamento é utilizado para garantir que o projeto seja concluído dentro do orçamento planejado e aprovado. São considerados nesta fase
8 Parte interessada - todos os envolvidos em um processo, por exemplo, clientes, colaboradores, investidores, fornecedores, comunidade, etc. O processo em questão pode ser de caráter temporário (como um projeto) ou duradouro (Wikipédia, <http://pt.wikipedia.org/wiki/Stakeholder>).
não só os insumos, mas também os recursos com pessoal, terceirização e treinamentos que se fizerem necessários.
• A “QUALIDADE” é planejada mesmo antes do início do processo do projeto, para que se satisfaça a expectativa dos patrocinadores e dos stakeholders.
• Os “RECURSOS HUMANOS” que serão necessários para atender aos objetivos, devem ser identificados na fase de planejamento, para evitar qualquer problema com questões como alteração no custo e atrasos no projeto.
• Por último, não menos importante, devem-se identificar os “RISCOS”. Ao fixar o planejamento é possível identificar um possível impacto negativo. Este impacto poderá desestabilizar o projeto e esta fase deverá principalmente descobrir como extirpá-lo, ou caso não seja possível amenizar qualquer impacto.
Determinando o planejamento, são iniciadas as “AQUISIÇÕES” ou contratos necessários para que o projeto possa transcorrer dentro de uma normalidade possível.
Execução do projeto
A execução do projeto resume-se em colocar o planejamento em ação, visando a atender aos objetivos. Na fase de execução, a área de conhecimento de integração, qualidade, recursos humanos, e comunicação são essenciais.
Entre as etapas da execução Rocha (2003) comenta:
A “INTEGRAÇÃO” deve ligar as outras áreas para que tudo possa ocorrer dentro do previsto.
Os “RECURSOS HUMANOS” formam as equipes dispondo de habilidades diferentes uns dos outros, são focos e pensamentos diferenciados o que torna esta uma etapa de grande complexidade de gerenciamento para o Gerente de Projeto.
A “COMUNICAÇÃO” cumpre, nesta fase, seu principal papel, pois dependerá da comunicação a fim de que os patrocinadores do projeto fiquem sabendo do andamento e de um possível
desvio
de meta que possa vir a comprometer ou não o resultado do projeto. A comunicação também manterá os stakeholders envolvidos informados em tempo hábil, para que não haja nenhum problema com fornecimento de material ou decisão atrasada em relação à falta de dados.Isso poderá acontecer utilizando-se desde a forma verbal até relatórios em mídia ou formal.
A “AQUISIÇÃO” trata-se de uma fase de cumprimento de propostas e contratos, obtendo as respostas dos fornecedores, sejam de produtos e/ou serviços.
Controle do projeto
O projeto deve ser monitorado de forma integral, principalmente quanto à questão prazos, e ainda para que o tempo não passe a ser mais importante de que outra área. Um exemplo que se pode relatar dos fatos comuns a projetos, é que quando este tende a atrasar, o gerente para cumprir os prazos estipulados, tende também a ultrapassar o custo com novas contratações ou aquisições.
Controlar consiste em coletar dados para fiscalizar o desempenho em relação ao planejamento. Isto poderá ser feito analisando variações do plano do projeto, decidindo se as ações corretivas se fazem necessárias para que o desempenho aconteça de acordo com o planejado, e decidir principalmente se o plano necessita de ajustes (ROCHA, 2003).
Sobre a fase de controle Rocha (op. cit.) cita:
1- A “INTEGRACÃO” faz parte desta fase com o propósito de implementar as políticas organizacionais e seus relacionamentos dentro da estrutura do projeto e da empresa. A preocupação principal da integração é coordenar as mudanças através do ciclo do projeto.
2- Nesta fase deve existir também um controle implícito dos “RISCOS”, para
“virtualizar” os impactos antes que estes ocorreram. A atividade de controle do risco deve ser voltada ao controle do conhecimento da área do “ESCOPO”, para não haver mudanças no custo ou tempo e principalmente no próprio produto do projeto.
3- O “TEMPO” e o “CUSTO” são etapas verificadas com maior facilidade na fase de controle, pois estes conhecimentos, normalmente são demonstrados por intermédios de ferramentas gráficas, que facilitam muito o controle.
4- A “COMUNICAÇÃO” na fase de controle é um instrumento de grande valia, pois através dela é possível precisar o andamento dos processos do escopo, cronograma, custo e a qualidade.
5- A “QUALIDADE” é um processo técnico de acordo com o produto que é na verdade o escopo do projeto, que deve ser mensurado em seus atributos e características, relatando a probabilidade de algo acontecer.
6- A gestão de “RISCO” é um processo para manter a equipe informada sobre qualquer anormalidade, seja esta negativa ou ainda uma oportunidade residual ou não, envolvendo plano de contingência, ações corretivas ou replanejamentos.
Encerramento do projeto
Normalmente esta fase acaba sendo negligenciada pelas equipes de gerenciamento de projeto, tornando-se o novo produto rotineiro dentro da empresa. O encerramento, no entanto, é uma fase importante onde a maioria dos stakeholders tomam conhecimento oficialmente desta etapa e poderão desfrutar do novo produto na sua integridade.
A fase de encerramento deve acontecer com uma “COMUNICAÇÃO” oficial e bem documentada revelando o encerramento administrativo. Também ocorre o encerramento dos possíveis contratos em andamento e das “AQUISIÇÕES” realizadas. Alguns contratos têm condições específicas e devem ser encerrados oficialmente, principalmente os que envolvem os “RECURSOS HUMANOS”.
Fonte BIBLIOGRÁFICA
ROCHA, Klinger Menezes de Holanda. Gerência de Projetos: uma visão em conformidade com o PMI – PMBOK Guide 2000. Dez 2003.
ANEXO B – Conceitos básicos de Diagrama de Gantt e Digrama de Redes
Diagrama de Gantt
Fundamentalmente, o diagrama de Gantt consiste de barras horizontais e paralelas que indicam atividades executadas, ou a executar, disposta em série numa escala de tempo horizontal, ou dispostas umas sobre as outras, indicando concomitância de prazos, conforme mostra a figura:
Figura: Diagrama de Gantt
A maior deficiência desta técnica reside na impossibilidade de se representar no diagrama a interdependência entre as diferentes atividades, pois o fato de atividades estarem programadas para períodos simultâneos não as torna necessariamente interdependentes.
Diagrama em Redes
O usuário de PERT/CPM irá empregar dois conceitos fundamentais: (i) Evento; e, (ii) Atividade.
Evento é o marco que denota o início ou o fim de determinada atividade. Em um projeto, os eventos são sempre apresentados por círculos, numerados em ordem crescente com a direção do progresso do projeto.
Uma atividade representa a ação que desloca o trabalho de um evento para outro, absorvendo tempo e/ou recursos no processo. É sempre representada por uma seta, orientada no sentido do início para o fim, sem escala gráfica.
O término da montagem de uma peça específica ou o início de determinado estudo são eventos de um projeto. A efetiva montagem desta peça e a realização deste estudo são atividades.
Figura: Diagrama de rede
A construção de uma rede PERT/CPM exige que se conheça:
1) a lista das tarefas que devem ser executadas para a conclusão do projeto, ou seja, as atividades propriamente ditas;
2) a definição das tarefas precedentes e as subseqüentes, ou seja, a ordem de execução das atividades;
3) os tempos de execução de cada tarefa, ou seja, a duração das atividades.
Qualquer projeto composto de atividades ordenadas pode ser enquadrado neste esquema gráfico. Para a elaboração da rede PERT, três regras bem definidas devem ser seguidas:
Regra I
"Cada atividade é representada por uma e somente uma seta na rede". Uma atividade pode, no entanto, ser desmembrada em outras atividades menores.
Regra II
"Duas atividades não podem ser identificadas pelo mesmo evento final e evento inicial".
Na prática, porém, duas atividades podem ser executadas simultaneamente, como mostra a figura:
Não é permitido
Figura: Diagrama de rede
Para contornar este problema, adiciona-se à rede uma atividade fictícia que não tem associado ao seu desenvolvimento nenhum consumo de tempo. As possíveis representações corretas para o caso de atividades concorrentes, ou simultâneas, seriam então:
Figura: Diagrama de rede
Atividades fictícias são também necessárias para estabelecer relações lógicas na rede, que de outro modo seriam de impossível representação. Considere um projeto com as seguintes atividades:
Atividade Descrição A Instalar equipamentos B Contratar operários C Inspecionar equipamentos D Treinar operários
Definindo-se a ordem de execução, obtém-se a seguinte lista de dependências:
Atividade Atividades Precedentes Atividades Subseqüentes
A - C, D
B - D
C A -
D A, B -
A princípio, a rede poderia ser:
Figura: Diagrama de rede
Regra III
“Para garantir a correta relação de precedência na rede, as seguintes questões devem ser atendidas quando cada atividade for incluída à rede: (i) que atividades precisam ser completadas imediatamente antes da atividade em questão poder ser iniciada?; (ii) que atividades precisam seguir esta atividade?; e, (iii) que atividades precisam ocorrer simultaneamente com esta atividade?”
Exemplo: Montar uma rede PERT/CPM para a troca de uma lâmpada queimada.
Atividade Descrição Dependência
A Providenciar lâmpada nova -
B Desligar o disjuntor A, C
C Providenciar uma escada -
D Retirar lâmpada queimada B
E Colocar lâmpada nova D
F Ligar o disjuntor E
G Jogar lâmpada queimada no lixo D
H Guardar a escada E
A rede correspondente seria:
Figura: Diagrama de rede
Cálculo de Redes PERT/COM
Em cada nó, ou evento, são computados os seguintes valores: (i) Cedo do Evento; (ii) Tarde do Evento.
O cedo de um evento corresponde à data mais cedo para dar início à execução das atividades que emanam deste evento, contada a partir do início do projeto, considerando-se que todas as atividades que chegam até este evento não sofram atrasos na execução.
O tarde de um evento corresponde à data mais tarde possível para atingir o evento sem que o projeto sofra atrasos.
Os valores de cedo e tarde do evento são incluídos na própria rede, junto ao número do evento. Uma forma prática para sua representação é:
Figura: Nó do Diagrama
Definição do Caminho Crítico, Folgas e Datas
As atividades inflexíveis são denominadas críticas, e a cadeia que elas formam denominam-se caminho crítico do projeto.
Caminho crítico é aquele no qual as atividades não têm folga para iniciar nem para terminar.
Uma maneira de apurar as folgas das atividades é utilizar-se das datas de realização das atividades:
Primeira Data de Início - é a data em que a atividade pode ser iniciada caso as atividades antecessoras foram iniciadas na primeira oportunidade e completadas nas durações estimadas.
Última Data de Início - é a data-limite de início de uma atividade para que o projeto não sofra atrasos.
Exemplo: Calcular as datas de realização e folgas totais das atividades, e definir o caminho crítico do PROJETO I.
Figura: Diagrama de PERT/CPM
Data de Início Data de Término Lista de
Atividades
Duração da
Atividade PDI UDI PDT UDT Folga
A 3 0 0 3 3 0
B 6 0 1 6 7 1
C 2 0 6 2 8 6
D 4 3 3 7 7 0
E 2 3 6 5 8 3
F 7 3 4 10 11 1
G 4 7 7 11 11 0
H 3 5 8 8 11 3
Caminho Crítico A - D – G
Elaboração do Cronograma
Primeiramente considera-se as atividades críticas, incluindo-as como linhas contínuas no cronograma. A seguir, as atividades não-críticas são incluídas no cronograma, indicando as datas de início mais cedo (PDI) e término mais tarde (UDT) de cada atividade, como datas- limite de execução das mesmas. Estes limites são unidos por linhas tracejadas, indicando que estas atividades poderão ter sua execução programada dentro deste intervalo, sem que haja prejuízo nas relações de precedência. Para cada atividade inclui-se ainda duas linhas contínuas de comprimento proporcional à duração da atividade. A primeira tem início na data de início mais cedo (PDI) e, por construção, tem término na data de término mais cedo (PDT), enquanto a segunda linha contínua tem início na data de início mais tarde (UDI) e final, portanto, na data de término mais tarde (UDT).
O cronograma para o PROJETO I será então:
Figura: Diagrama do cronograma com caminho crítico
Fonte BIBLIOGRÁFICA
MAYERD, Sérgio Fernando. Programação de Projetos com PERT/CPM. Departamento de Engenharia de Produção e Sistemas. Universidade Federal de Santa, Disponível em:
<http://www.deps.ufsc.br/~mayerle/private/eps5102/PERT_CPM.pdf>, acesso em: acesso em 19 JAN 2008.