O documento discute: 1) a importância de projetos e o fato de que apenas 34% dos projetos de TI são bem-sucedidos; 2) o conceito de projeto como um empreendimento temporário para criar um produto ou serviço único; 3) as fases do ciclo de vida de um projeto, incluindo iniciação, planejamento, execução, monitoramento e encerramento.
2. Porquê o interesse em Projectos?
Cronica do Chaos - sobre o universo de projectos
em TI – só 34 % são bem sucedidos (2003
Standish Group) :
3. Conceito de Projecto
Um PROJECTO
é um empreendimento temporário
realizado com o objectivo de
criar um produto, serviço ou resultado
único
Exemplos:
Desenvolvimento de um produto de software
Construção de uma casa
4. O Ciclo de Vida do Projecto
Monitorizar
Planear
Iniciação Encerramento
Executar
5. O Ciclo de Vida do Projecto
Monitorizar
Iniciação
Objectivo
Planear
Autorização
Encerramento
Identificação
de partes
interessadas
Executar
6. O Ciclo de Vida do Projecto
Monitorizar
Iniciação
Objectivo
Planear
Autorização
O Trabalho
que será feito Encerramento
Identificação
de partes
interessadas
Executar
7. O Ciclo de Vida do Projecto
Monitorizar
Iniciação
Objectivo
Planear
Autorização
Âmbito
Custo
Encerramento
Identificação
de partes Prazo
interessadas Qualidade
RH
Riscos
Satisfação do Cliente
8. O Ciclo de Vida do Projecto
Monitorizar
Iniciação
Objectivo
Planear
Autorização
O Trabalho
que será feito Encerramento
Identificação
de partes
interessadas
Executar
Completar o
trabalho
9. O Ciclo de Vida do Projecto
Monitorizar Encerramento
Iniciação
Obter
Objectivo aceitação final
Planear do cliente
Autorização
O Trabalho
que será feito Fechar rel.
contratuais
Identificação
de partes
interessadas Registar lições
aprendidas
Executar
Completar o
trabalho
Bom dia, o meu nome é Maria João Costa, e estou aqui para vos falar um pouco sobre o ciclo devida de um projecto.
Ora bem, porque é que se começou a sistematizar esta área da gestão de projectos? Porque na década de 90, algumas entidades decidiram apurar qual a proporção de sucesso e insucesso dos projectos, e verificaram que as taxas de insucesso eram muito elevadas. Para terem uma ideia ainda em 2003 um estudo (Cronica do Chaos, do Standish Group) apurou que (num universo de 60000 projectos, de 2001 a 2003) a percentagem de projectos em TI francamente bem sucedidos era de 34%, sendo que 51% dos projectos apresentava falhas ao nível do âmbito, prazo ou custos, e 15 % dos projectos falhavam de todo.O queria dizer que, de uma forma ou de outra, havia muito trabalho e dinheiro a ser deitado fora. Então, vários autores começaram a organizar mais a informação relativa à gestão de projectos, e decidiu-se reunir num conjunto de documentos uma serie de boas praticas relativas a essa área. O documento principal a este nível é conhecido como PMBOK e vai na sua 4ª edição. E, de acordo com o PMBOK um projecto é um empreendimento temporário realizado com o objectivo de criar um produto, serviço ou resultado único. Este conceito é muito abrangente, abrange tanto o desenvolvimento de um software como a construção de uma casa ou de uma ponte. Durante esta sessão, vou ter como referência o exemplo do desenvolvimento de um programa de cálculo de salários.
Ora bem, porque é que se começou a sistematizar esta área da gestão de projectos? Porque na década de 90, algumas entidades decidiram apurar qual a proporção de sucesso e insucesso dos projectos, e verificaram que as taxas de insucesso eram muito elevadas. Para terem uma ideia ainda em 2003 um estudo (Cronica do Chaos, do StandishGroup) apurou que (num universo de 60000 projectos, de 2001 a 2003) a percentagem de projectos em TI francamente bem sucedidos era de 34%, sendo que 51% dos projectos apresentava falhas ao nível do âmbito, prazo ou custos, e 15 % dos projectos falhavam de todo.O queria dizer que, de uma forma ou de outra, havia muito trabalho e dinheiro a ser deitado fora. Então, vários autores começaram a organizar mais a informação relativa à gestão de projectos, e decidiu-se reunir num conjunto de documentos uma serie de boas praticas relativas a essa área. O documento principal a este nível é conhecido como PMBOK e vai na sua 4ª edição. E, de acordo com o PMBOK um projecto é um empreendimento temporário realizado com o objectivo de criar um produto, serviço ou resultado único. Este conceito é muito abrangente, abrange tanto o desenvolvimento de um software como a construção de uma casa ou de uma ponte. Durante esta sessão, vou ter como referência o exemplo do desenvolvimento de um programa de cálculo de salários.
Tendo o conceito de projecto, uma das abordagens sistematizadas propostas é a do ciclo de vida do projecto. O ciclo de vida tem 5 fases:A Iniciação, o Planeamento, e a Execução, a Monitorização e o Encerramento.
A primeira fase é da Iniciação. Na fase inicial do projecto, é definido o objectivo maior do projecto, por exemplo desenvolver um sistema de processamento de salários, é dada a autorização por parte do Director da empresa que vai desenvolver o software, para começar a trabalhar, e devem também identificar-se quem são as partes interessadas no desenvolvimento do projecto. As partes interessadas são as pessoas ou entidades a cujos interesses podem ser positiva ou negativamente afectados pela execução, conclusão ou cancelamento do projecto .Exemplos: O Director da empresa, o Gestor do projecto, a equipa de projecto, o cliente, por exemplo a senhora que irá trabalhar com o novo Sistema na empresa cliente. Porque é que é útil identificar logo no inicio as partes interessadas? Porque, quanto mais tarde se manifestarem, mais alterações irão trazer ao projecto. Convém identificá-las de início, e criar estratégias de comunicação que se concretizem durante todo o projecto. É importante saber quais são as suas expectativas e ir fazendo a gestão dessas expectativas, para no final não dizerem “ah! Isto não faz nada do que eu pensava!”. Portanto, falamos com as partes interessadas e se for exequível transformamos as expectativas em requisitos, e comprometemo-nos a apresentar esses resultado, por exemplo um determinado relatório. Se não for exequível, é melhor esclarecer também o que é que o projecto não vai fazer. Não vai permitir tirar cafés, por exemplo.
Seguidamente, entrar na fase do planeamento. Aqui vai-se planear o trabalho necessário para completar o projecto. E é nesta fase que iremos a ter em conta as várias vertentes do projecto que têm que ser equilibradas.
Ao planearmos o âmbito é fundamental assegurar que inclui todo o trabalho necessário e apenas o trabalho necessário para ser completado com sucesso. Ou seja não se deve desenvolver funcionalidades que o cliente não pediu.O custo e o prazo de execução têm que ser estimados da forma mais precisa e realista possível, de forma a conseguirmos cumprir o que prometemos.A qualidade deve ser planeada de forma a que se cumpram os requisitos do produto. E há que ter em atenção os recursos humanos de que dispomos para desenvolver o projecto.A arte do gestor de projectos está em manter estas vertentes em equilíbrio. Porque aqui tudo tem a ver com tudo. E a pedra de toque para este equilíbrio é necessariamente a satisfação do cliente. O cliente é que sabe qual é a sua prioridade: pode ser cumprir o prazo, por exemplo. Por isso, quando são pedidas alterações ao projecto na fase de execução, e são pedidas muitas alterações, devemos sempre avisar o cliente de quais as consequências dessa alteração.Se o cliente altera o âmbito, por exemplo, se exige uma nova funcionalidade, quando o projecto já está avançado, o que é muito comum, em principio, isso altera o prazo de conclusão. Mas se tivermos mesmo que manter o dead line inicial, então vamos alterar os custos, porque teremos que reforçar a equipa ou trabalhar aos fins de semana. Um dos pontos de honra deve ser, manter o planeado para a qualidade. E tem mesmo que ser um ponto de honra, senão o primeiro prazo a ser encurtado é logo o da fase de testes e a qualidade ressente-se inevitavelmente.Finalmente há que ter em conta nesta fase, o tratamento dos riscos do projectoOs riscos do projecto devem ser identificados e deve ser planeada uma resposta à sua ocorrência. Por exemplo se eu sei que na minha equipa só um elemento domina uma determinada linguagem que aqui é fundamental terei que planear uma formação para pelo menos outro elemento da equipa, para que este possa substituir o primeiro no caso de aquele ficar doente.Um outro risco muito comum é o do atraso na entrega de equipamentos. Imaginem que, para este sistema e cálculo de salários poder ser utilizado é necessário que todas as senhoras dessa área do cliente tenham novos computadores. E planeamos que a formação na ferramenta começa no dia 20, assumindo que os computadores já foram entregues nessa data. E se não tiverem sido? Tem que haver uma resposta planeada, um plano B.
E, depois de planearmos a equipa irá fazer o trabalho de acordo com o planeado. E, ao mesmo tempo o gestor de projecto efectuando a monitorização e o controlo desse trabalho. Verifica-se se a performance está a progredir conforme o previsto. E, se não estiver, poderão ter que se tomar medidas correctivas, que podem obrigar ao replaneamento… e é uma sequência cíclica até ao fim do trabalho. Quando o trabalho termina, entramos na fase do encerramento.
O principal objectivo desta fase é obter a aceitação final do cliente. O cliente diz “ok, é isto mesmo!”. Fecham-se as relações contratuais que existam e é uma boa pratica registar as lições aprendidas. Isto, para que os próximos possam aprender com a nossa experiência.