O que é o PRINCE2?

“Projects in Controlled Environments” ou, em breve, PRINCE2 está a tornar-se um dos métodos mais populares e amplamente utilizado para a gestão de projecto. Pouco utilizado no nosso país, onde é quase desconhecido, é usado no sector privado e público e tornou-se o standard de facto para gestão de projectos no reino Unido.

Continuando o sucesso obtido no Reino Unido, o interesse por este método começou a espalhar-se pelo mundo. Os países em que se tornou mais usado são a Holanda, Bélgica, Alemanha, África do Sul, Austrália e mesmo nos EUA.

A que se refere o 2 em PRINCE?

O PRINCE” nasceu em 1975, a partir da metodologia PROMPTII. Esta foi substituída pela PRICE em 1989, passando a ser o standard para todos os projectos de sistemas de informação do governo do Reino Unido. Em 1996, a metodologia foi relançada como uma metodologia genérica de gestão de projecto para todos os projectos do governo britânico.

Porque foi introduzido o PRINCE?

Podemos dizer que o sector público de qualquer país não pode dizer com fundamento que a forma como faz a gestão dos seus projectos seja exemplar. Antes pelo contrário! O PRINCE e o PRINCE2, posteriormente, foram introduzidos para enfrentar as causas comuns de fracasso nos projectos, muito em especial no sector público.

Como actua o PRINCE2?

PRINCE” é uma estrutura de boas práticas que apoia os gestores a realizar projectos em tempo e dentro do orçamento. Divide os projectos em etapas claramente definidas com um princípio, meio e fim. Concentra-se na realização de produtos em vez de realizar actividades. Todos os projectos devem ter um business case e um plano que são periodicamente revistos para verificar se continuam viáveis.

Um projecto PRINCE” tem as seguintes características:

¶ Um ciclo de vida definido e finito

¶ Produtos de negócio definidos e mensuráveis

¶ Um conjunto correspondente de actividades para realizar produtos de negócio.

¶ Uma quantidade definida de recursos

¶ Uma estrutura de organização, com responsabilidades definidas, para gerir o projecto.

Como é estruturado um projecto PRINCE2?

No centro da metodologia está o Board do Projecto, constituído pelo cliente, representantes do utilizador e do fornecedor. O Gestor de Projecto reporta a este board, com regularidade, o progresso, os problemas e o board decide como deve o projecto proceder.

Quais são os benefícios do PRINCE2?

PRINCE2 dedica-se realizar os projectos certos, no tempo certo pelas razões certas. Fornece sistemas comuns, procedimentos e linguagem para os projectos. Oferece ainda:

¶ Melhor controlo e uso dos recursos

¶ Meios de gerir riscos e questões

¶ Pontos de decisão flexíveis

¶ Revisões regulares do progresso em relação ao plano de projecto e ao business case.

¶ Garantia de que o projecto continua a ter uma justificação de negócio

¶ Visibilidade antecipada dos problemas

¶ Boas comunicações entre a equipa de projecto e os outros stakeholders

¶ Um mecanismo para gerir desvios ao plano do projecto

¶ Um processo para capturar as lições aprendidas.

Com isto tudo PRINCE” permitirá poupar tempo e dinheiro ao mesmo tempo que se realizam com mais efectividade os projectos.

Gestão de Projecto e Impacto no Sucesso dos Projectos

Na próxima semana, inicio uma acção de formação em Gestão de Projecto para uma empresa de desenvolvimento de software portuguesa. As 3 palavras desenvolvimento, software e portuguesa parecem que se contradizem. Mas não! É uma empresa com sucesso, especializada no software e portuguesa.

A pergunta que me coloquei foi: como posso contribuir para com a Gestão de Projecto melhorar o seu sucesso?

Ao lidar com projectos de TI,  a utilização de técnicas de gestão especializada de projecto poderá ser muito benéfica para o progresso dos projectos em curso e, sobretudo, para o crescimento da taxa de sucesso no longo prazo. O planeamento e a gestão de Projectos pode ser complicado por muitas razões e isso faz com que a capacidade de concluir com sucesso se torne um activo de muito valor.

Algumas complicações comuns

A dificuldade na gestão de projectos de TI reflecte-se na elevada taxa de insucesso dos mesmos. De facto, um relatório de 2009 publicado pelo The Standish Group indica que apenas 32% dos projectos de tecnologia da informação desenvolvidos pelas empresas foram considerados bem-sucedidos.

Quase um quarto de todos os projectos de TI falharam, enquanto 44% foram considerados «comprometidos», ou seja, foram considerados atrasados, a gastar mais que o orçamento ou não indo ao encontro de todos os requisitos do projecto. Com esta taxa de fracasso, é fácil perceber por que são especiais as competências e conhecimento de gestão de projectos em TI (e, muito especialmente, em software) e a sua necessidade para manter os projectos na linha.

Em geral, os projectos falham por um conjunto de razões. Por exemplo, um projecto pode falhar devido a planeamento pobre ou insuficiente, a um âmbito mal verificado ou a uma escala de tempo irrealista. Embora estes sejam problemas comuns em todos os tipos de fracasso em projecto, a natureza tecnológica dos projectos torna este tipo particular de situações mais provável de se desenvolverem.

Entre os factores que contribuem para o fracasso dos projectos estão:

· A falta de profissionais com experiência especializada em gestão de projecto;

· As complicações derivadas da utilização de tecnologia incompatível ou insuficientemente madura;

· A falta de compreensão geral acerca dos desafios específicos dos projectos de tecnologia de informação por parte daqueles responsáveis pelo seu planeamento, execução e controlo

A formação e as boas práticas em Gestão de Projecto

Apesar de existirem desafios específicos para superar quando se trata gestão de projectos de, a realização de alguma formação neste campo pode conduzir a uma maior compreensão de como abordar as questões e contornar os problemas. Ao participar em cursos de gestão de projecto com formação especificamente para tecnologia da informação, você pode aprender como aplicar estratégias comprovadas para projectos de TI, a fim de melhorar os resultados e gerar processos mais eficientes.

Técnicas como a criação de métricas para medir o desempenho uniforme do projecto e padronizar a linguagem utilizada para descrevê-las, Sistemas de controlo de projecto aceites e utilizados pela equipa e processos de colaboração durante a execução, são alguns conceitos básicos de gestão de projectos que podem melhorar muito os resultados do projecto quando envolve tecnologia de informação. Manter monitorização estreita de prazos e custos do projecto e âmbito do projecto de gestão são vitais quando está a tentar garantir um projecto de tecnologia da informação se mantem no caminho certo.

Luís Quintino

Análise de Negócio numa Equipa Agile

Os processos, produtos e relações alteram-se numa equipa Agile.

Como planeamos o trabalho, entregamos o produto, representamos os requisitos, partilhamos o conhecimento, interagimos com a equipa e cliente, gerimos os requisitos em mudança e documentamos os requisitos será completamente diferente dos projectos tradicionais em Waterfall.

De facto, pass a fazer parte de uma equipa de colegas altamente colaborativos com um foco furioso em realizar valor, negociando a realização de valor em ciclos curtos e apoiando os parceiros de negócio para compreenderem o que realmente necessitam, não só no imediato, mas também conforme o produto vai aparecendo em pequenos pedaços utilizáveis.

Que muda

Os analistas de negócio devem ceder o controlo dos requisitos, a relação com o cliente e a documentação usual de requisitos. Porquê? Só porque na equipa Agile você entrega software valioso a trabalhar numas poucas semanas. E você (a sua equipa e o seu cliente) não sabem qual será exactamente o produto final mesmo até ao momento em que se começa a construí-lo, entrega-lo e obter, então, feedback sobre ele. Só então apreendemos qual é a real necessidade.

Um projecto Agile é tudo acerca de suspender o controlo durante tanto tempo quanto o possível.

Até as funções da equipa podem ser ambíguas: As especificidades podem variar, mas uma equipa Agile colabora para entregar um conjunto de requisitos a que se comprometeu. Cada membro da equipe está pronto, mesmo ansioso a fazer o que for preciso para que isso aconteça, não importa o que ditarem as responsabilidades oficiais do trabalho .

É provável que não seja o único a elicitar, analisar e especificar requisitos. A equipa está focada em entregar um software «utilizável» em ciclos curtos (iterações), assim as suas actividades podem cruzar sobre outras actividades que entusiasmam as suas competências, capacidades e interesse.

Por exemplo, é pouco provável que você se identifique ou mesmo crie e execute testes de aceitação do utilizador: a validação em cima do produto. As suas competências soft e a compreensão das dependências dos requisitos tornam-no um bom candidato para realizar o planeamento de workshops de definição do mapa de trabalhos do produto e planos de release.

Como Analista de Negócio Agile você deixou de estar preso à grande e complexa documentação de requisitos e modelos. Em vez disso, vai influenciar os seus parceiros de negócio e equipas a repensar que tipo de (e quanta) documentação é necessário. Você pode entregar a documentação em pequenos pedaços, juntamente com os pequenos e úteis pedaços de requisitos que a sua equipa de entrega em cada iteração (muitas vezes sob a forma de user stories). Você pode passar a desenvolver uma documentação leve de produto, de utilizador ou de suporte.

Novo tipo de trabalho

O seu trabalho é, ao mesmo tempo, táctico e estratégico: você tem de entender o ponto de vista global (o mapa de visão do produto e os planos de release), mantendo ao mesmo tempo uma mão firme no agora (a iteração corrente). Tem de ter a disciplina e a flexibilidade para operar em modos múltiplos (o «agora» da iteração corrente e o «depois» das próximas iterações.

O seu trabalho será transparente. Você obterá melhores estimativas e ao trabalhar com seus companheiros da equipa multifuncional pode prever com segurança quanto o software a sua equipa pode entregar em cada iteração. A visibilidade de planeamento da iteração, as demonstrações de final de iteração, e as retrospectivas não permitem permitir nenhum esconso. Você vai sentir-se mais em controlo, já que vai ser abertamente responsável perante seu cliente, a equipe, e você próprio.

Luís Quintino