O Risco, uma técnica simples

Todos os projectos são diferentes e a melhor forma de identificar os potenciais riscos dentro de projectos complexos é recorrer à experiência de projectos passados dentro da mesma área. Mesmo com indústrias diferentes há muitas áreas de risco potencial que podem ser as mesmas ou similares, existindo obviamente áreas específicas.
A primeira abordagem é obter uma visão global das diferentes áreas do projecto tais como:

• Âmbito
• Equipamento
• Tecnologia
• Pessoas
• Escala de tempo
• Orçamento

Em seguida, escolha cada uma destas secções e decomponha-a com mais detalhe. Pode ser útil uma sessão de brainstorming com um pequeno grupo de membros da equipa em representação de diferentes partes dos departamentos e grupos envolvidos. Não deve ser uma actividade que consuma muito tempo, mas é crítica para a gestão com sucesso do projecto.

Âmbito

A natureza do âmbito é a definição do que é e do que não é incluído nos requisitos que o negócio pretende obter. Assim, as áreas que podem correr mal ou causar problemas serão questões que terão a ver com o que é e não é escrito neste documento ou que não foi suficientemente descrito nos documentos do projecto. Os primeiros riscos identificados podem ser «requisitos de negócio pobremente definidos», «falta de pessoal experimentado» ou «requisitos de negócio que não foram aprovados pelo cliente».

Equipamento

Esta área de foco deve incluir o equipamento requerido para concluir o projecto em vez de qualquer equipamento que seja uma entrega ou um resultado final do projecto. Pode incluir hardware de computadores, equipamento fabril para a realização do produto final ou um conjunto de outras possibilidades dependentes do projecto particular. Ao identificar os riscos nesta secção deveremos considerar riscos como «confiança do equipamento», «facilidade de substituição se avariar», «custos da substituição do equipamento avariado».

Tecnologia

Esta secção cobre todas as áreas que tenham a ver com o uso de computadores excepto o hardware físico e outras áreas de inovação ou de desenvolvimento envolvidas no projecto. Deve ter-se atenção às dependências com pacotes de software (quer internos como externos) e sistemas de gestão de bases de dados, com outros fornecedores de tecnologia a usar no projecto.

Pessoas

Até que ponto são críticas as pessoas existentes para o sucesso do projecto. Eles possuem conhecimentos especializados que podem ser difícil ou muito dispendioso obter em outro lado. Deve enfrentar-se também a possibilidade de haver uma grande mobilidade das pessoas ou, ao contrário, as equipas estão bem motivadas e estabelecidas e irão permanecer durante o decurso do projecto. Se for o caso de ser gestor de um projecto grande e global, pode até ocorrer que não conheças as equipas em localizações diversas e só tenha contacto com gestores de projecto locais. O conhecimento sobre a dinâmica e construção das equipas pode ser muito útil para a avaliação de riscos potenciais.

Escala de Tempo

Os primeiros problemas têm a ver com o detalhe e correcção das estimações efectuadas para todo o projecto e cada actividade individual. Se o projecto for qualquer coisa diferente de tudo o que fez antes, serão as estimativas meras adivinhas? Quando as escalas de tempo foram determinados por um imperativo de negócio por virtude uma data determinada pelo mercado são acrescentados novos factores de risco no agendamento. Todos estes factores afectam o tipo e a probabilidade dos riscos para as escalas de tempo do projecto.

Orçamento

Se o orçamento foi determinado por um imperativo do cliente em vez do custo real pode não oferecer os meios para concluir o projecto. Um orçamento limitado, por outro lado, não é necessariamente uma causa de insucesso para o projecto. Um bom gestor de projecto possuirá as competências requeridas para obter o máximo de um orçamento limitado e minimizar também os riscos dentro de um projecto deste tipo.

Em geral

De facto muitos factores que gestores de projecto menos experientes podem pensar que criam um projecto mais «arriscado» são muitas vezes factores que podem ser facilmente geridos porque ocorrem frequentemente, como ó caso de recursos limitados, escalas de tempo apertados ou orçamento limitado. É mais provável que o risco provenha de factores que ocorrem com menos frequência como tecnologia ainda não totalmente testada ou produtos, e estes podem tirar um projecto do seu curso.
Desta forma, a identificação dos riscos num projecto é crítica para os gerir com sucesso e estas áreas que, em breve, descrevemos são as mais importantes para o gestor do projecto considerar ao identificar os riscos. Para projectos maiores e mais complexos, a gestão de risco será um trabalho a tempo inteiro e exige que o gestor de projecto tenha a formação e as competências para o assumir com efectividade
.

Recuperar o Controlo do Projecto

Um projecto que está fora de controlo, quer devido a um orçamento ultrapassado seja quanto a desvio no planeamento, não vai voltar ao caminho sem um esforço sério e um compromisso por parte das pessoas envolvidas no projecto e de parte da organização que o realiza. Felizmente existem três processos simples e cumulativos para ajudar o gestor do projecto a recuperar o controlo e a resgatá-lo do fracasso.

1. Determinar o estado actual do projecto

Revisão de todas as tarefas e actividades para que se possa determinar exactamente onde o projecto está em relação com o cronograma e o orçamento real. Ignore qualquer custo estimado anteriormente e os tempos definidos e concentre-se em determinar o status real.

Deve rever todos os relatórios disponíveis e falar com os membros da equipe para explicar o que quer saber exactamente, qual o progresso que tem sido feito, independentemente de qualquer estimativa anterior, promessas ou compromissos. É fundamental para controlar a recuperação do projecto que você possa começar a partir de uma base conhecida. Dessa forma, o replaneamento tem a melhor possibilidade de sucesso e pode, com esperança e trabalho, evitar que o projecto se transforme num desastre.
Se não tentar determinar e documentar todas as hipóteses, as óbvias e as não tão óbvias nas fases iniciais do projecto, agora é o tempo de fazê-lo. É vital ser persistente e garantir que todas as premissas são conhecidas e documentadas.
Deve não apenas reavaliar o status do projecto em termos de tempo e orçamento, mas também reavaliar os recursos disponíveis em termos de competências e pessoas. Se não levar isso em conta no replaneamento e reagendamento não vai garantir que todos saibam o que você pretende para que o projecto seja um sucesso.

2. Reafirmar o objectivo do projecto

Certamente que não foi uma miragem o que garantiu os compromissos com o projecto, o que obteve a garantia do financiamento e o que permitiu que o projecto arrancasse. É função do gestor de projecto lembrar agora às pessoas a visão original e tentar reacender algum do entusiasmo com que o projecto começou.

O objectivo de negócio deve ter sido claramente definido e documentado no início do projecto, mas se não foi esse o caso, então agora está na hora de corrigir esse problema específico. Irá assim ajudar as pessoas a relembrar os benefícios que o projecto na sua conclusão terá para eles, como indivíduos, bem como para a organização no seu conjunto.
Devem ser realizadas as acções que permitam envolver as pessoas no projecto e garantir que sabem a importância de cada actividade que completam, para o sucesso global do projecto. Inspirar a equipa e fazer que todos os elementos se sintam valorizados. Isto pode parecer banal, mas é realmente vital para garantir que o projecto permanece controlado e se conclui em sucesso.

3. Decidir como atingir o propósito do Projecto

Agora que já realizou uma avaliação exaustiva da situação do projecto no que diz respeito ao orçamento, ao cronograma, às pessoas e às suas competências. Você sabe que nesse processo comunicou e reforçou a visão do projecto e o objectivo de negócio a todos os participantes do projecto e especialmente aos membros da equipa.

O próximo passo é planear a abordagem que lhe permitirá, a partir do presente estado, alcançar a conclusão com sucesso do projecto.

Pode ser que, em primeiro lugar, alguns dos factores que têm retirado o projecto do seu curso ainda existam e, portanto, pode haver pouca razão para optimismo quando se trata de replaneamento para a finalização do projecto. Mas temos de planear – se necessário teremos de reavaliar o status do projecto e voltar a replanear dentro de algumas semanas ou meses. De qualquer forma para poder avançar é necessário realizar agora um plano total.

Em alguns sectores da indústria, tal como as TI, que estão rapidamente a mudar e que podem ter uma alta rotatividade de pessoal é praticamente impossível planear um projecto do início ao fim que não necessite de ser reavaliado e replaneado em vários estágios ao longo do projecto. Não deixe que o facto disto acontecer possa incutir um sentimento de fracasso na equipa. Em algumas indústrias isto é normal e um plano altamente detalhado é improvável que vá sem uma ligação com um programa mais complexo.

As finanças e outros recursos podem mudar durante a execiçoa de um longo projecto e ogestor de projecto tem que saber como recuperar o controlo de um projecto afectado por circunstâncias imprevistas. Tratar estas coisas como uma oportunidade para voltar a entusiasmar a equipa e lembrar a todos a visão inicial do projecto, em seguida, avançar para a conclusão em sucesso do projecto.

LQ

O Essencial da Gestão de Projecto

Vou estar uns dias em África em consultoria de gestão de projecto e lembrei-me de relembrar o mais essencial na gestão de projectos. Não são técnicas, antes é a atenção para com coisas que não devemos esquecer.

Muito poucos planos de projecto são simples ou directos, porque têm sempre tantos factores contributivos que devem ser acautelados. Quais são exactamente todas as actividades que são requeridas e quanto tempo tomará cada actividade? Quais são as dependências entre as actividades? Algumas actividades podem exigir competências especializadas ou formação e empreiteiros podem ter de ser contratados para alguns aspectos do projecto. O esboço inicial pode não estar documentado de forma completa e problemas e omissões podem vir a revelar-se durante a etapa de planeamento. Pode ainda existir um prazo irrealista com que entramos em conflito.

São muitas questões que revelam uma pequena parte da complexidade do trabalho de um gestor de projecto.
 

Tempo e dinheiro

Os Gestores de Projecto podem sofrer enormes pressões para concluir o projecto dentro de um prazo fixo (deadline, que significa linha de morte), que foi estabelecido devido a factores fora do seu controlo. Pode ser uma questão de marketing em que é crítico o tempo para o mercado de um novo produto: pode ser um requisito do investidor ou qualquer outra razão económica, social ou mesmo política. Qualquer que seja, é dever do gestor do projecto trabalhar em função desta. Mas o pior é quando é essencial encolher todas as actividades necessárias dentro do tempo agendado e não permitir nenhuma derrapagem.

É completamente irrealista pensar e esperar que não seja necessária nenhuma contingência no agendamento planeado de qualquer projecto, seja grande ou pequeno. Então o que que pode ser feito se todas as actividades requeridas não podem simplesmente ser realizadas dentro do tempo disponível? Mesmo assumindo que tem estimativas razoáveis para estas actividades (tenha a certeza que tem) então a melhor opção será negociar com os sponsors do projecto para escalar os requisitos quer pela remoção de alguns aspectos ou pela alteração dos resultados finais. É sempre melhor entregar um produto funcional sem dezenas de campainhas e assobios do que entregar um produto como milhares de funcionalidades mas sem cumprir de forma cabal a sua função básica.

Pesquisas realizadas entre pessoas afectadas pela conclusão de um novo produto realçam o facto de que os utilizadores estão normalmente só interessados no trabalho básico do produto porque o seu projecto últra-ambicioso então tem de negociar uma redução de funcionalidades do resultado final.

Garanta, assim, que há sempre alguma contingência de tempo incluída no seu plano e se o seu agendamento não aceita isto porque o projecto é demasiado ambicioso então deve negociar por uma redução das funcionalidades nos resultados finais. O mesmo aplica-se com o custo do projecto – mantenha-se dentro do orçamento reduzindo as funcionalidades em vez de criara atalhos e realizar um produto ou serviço de baixa qualidade.

Planear um projecto é equilibrar entre alta qualidade de um produto ou serviço no fim do projecto e uma atitude realista e responsável relativamente à escala de tempo e custos envolvidos. Estes dois aspectos não se excluem mutuamente e com as competências certas podem com muita efectividade ajustar-se no equilíbrio correcto.
 

Pessoas

Pode ter a sorte de, como gestor de projecto, poder seleccionar os membros da sua equipa, mas muitas vezes a equipa é aquela que lhe foi atribuída. Isto é particularmente verdadeiro quando o trabalho é atribuído a sub-empreiteiros ou parceiros.

Em qualquer dos casos o elemento chave que irá afectar todo o projecto e a sua capacidade de o gerir com eficiência é até que ponto estão motivados os membros da equipa. Para grandes projectos deverá poder nomear algumas pessoas, obter o seu compromisso com o projecto e garantir de forma contínua que o trabalho destes com os membros das equipas irá envolver todos no compromisso com o projecto.

Os gestores de projecto possuem diferentes competências, personalidades e métodos de trabalho e desta forma é difícil definir uma abordagem que venha a funcionar melhor do que outra. O factor chave para obter o compromisso por parte da equipa é alimentar a individualidade própria de cada membro da equipa. Isto significa referenciar quando foi feito um bom trabalho e elogiar por isso, interessar-se pelas suas preocupações ou problemas com o projecto e acompanhar as questões entre os diferentes membros da equipa como, por exemplo, choques de personalidade.

Pode pensar que isto não faz parte da função de um gestor de projecto, mas tente só assumir um interesse pessoal com os membros chave da equipa do seu próximo projecto e veja por sim próprio qual a diferença que tem a construção de uma equipa em que se valoriza cada um, em que se confia em cada um e se consegue trabalhar com um verdadeiro envolvimento.
 

Técnicas de Planeamento

Como em quase todas as áreas de negócio hoje, existem pacotes de software disponíveis para tornar mais fácil o trabalho do gestor de projecto. Contudo para os utilizar é essencial uma compreensão global dos princípios básicos do planeamento de projecto para obter mais do uso destas ferramentas. As ferramentas serão sempre aquilo que o trabalhado é.

Algumas das ferramentas frequentemente utilizadas em gestão de projecto são o Brainstorming, os Diagramas de Causa e Efeito, os Gantt Charts e a Análise do Caminho Crítico.

Tal como o brainstorming é uma técnica útil durante a análise de negócio e de levantamento de requisitos também pode ser muito útil na fase de planeamento para identificar as relações entre as actividades, para desenvolver ideias de eficiência ou de poupanças em custos e desperdícios, ou mesmo para levantar questões e destacar problemas potenciais.

Na etapa de planeamento os gráficos e diagramas são ferramentas úteis para visualizar todas as questões e mais ainda. Podem ajudar a clarificar os diferentes aspectos do plano e, em função do tipo de projecto , podem ainda servir por muitas outras e diferentes razões.

LQ

Planear um Projecto com Work Breakdown Structure e Rede Lógica

Os projectos não acontecem, precisam de planeamento. Este envolve toda a equipa de projecto no desenvolvimento do plano, este não é um trabalho isolado do gestor do projecto. Esta participação garante que é considerada a experiência é considerada e que todas as pessoas se comprometem a fundo e dessa forma são co-proprietários do plano. Um bom plano oferece o seguinte:

Um mapa da estrada (incluindo milestones compreensíveis) que pode ser seguido por toda a gente da equipa.

• Uma escala de tempo realista para o projecto.
• Detalhes dos requisitos dos recursos.
• Validação do custo estimado.
• Identificação da derrapagem das actividades.
• Alerta precoce para os problemas.

Vale a pena usar a experiência anterior e as lições aprendidas em projectos similares.

• Quanto tempo demorou?
• Quanto custou?
• Quais eram as áreas de problemas?
• Quais eram as áreas com sucesso?

A execução de um projecto sem um plano é tolice. Trabalhar sem saber o destino é susceptível de conduzir a problemas e possíveis falhas. Executar um projecto sem um plano, é como tentar encontrar o caminho numa cidade estranha, sem um mapa. Como diz o ditado, "Se você falha em planear, está a planear falhar."

Work Breakdown Structure (WBS)

Para identificar as actividades individuais de um projecto, é útil criar uma estrutura de divisão de trabalho. A WBS é a base para o plano do projecto detalhado. Ponha a equipa a discutir todas as actividades e subactividades do projecto, sem seguir uma ordem particular. Vamos anotá-las em post-its e colocá-las num quadro branco. Logo que todos pensaram em muitas actividades, passamos a organizar as notas em grupos de acordo com as grandes áreas de actividade. Adicione, altere, remova e embaralhe as notas até que a WBS esteja precisa, completa e lógica. O propósito de uma WBS é decompor o projecto em etapas e sub-etapas.

Rede Lógica (Gráfico de Tempo)

Uma Rede Lógica mostra a sequência de actividades num projecto ao longo do tempo. Ela mostra que uma actividade logicamente precede ou segue uma outra. Criar num post-it um Start (à esquerda) e outro com End (à direita) e colocá-los no quadro branco. Organizar as notas post-it daWBS na sequência lógica das actividades da esquerda para a direita. Junte as notas com setas de entrada e saída, algumas podem ter mais de uma seta. Todas as linhas de conexão em uma rede entrar à esquerda (início) da caixa de actividade (nota pegajosa) e sair à direita (final). As linhas não entram no topo nem saem do fundo da caixa de actividade.

Não são permitidas linhas sem ligação. Todas as actividades devem se ligar a uma outra actividade, ou ao início ou ao fim do projecto. Escrever o tempo que cada actividade irá tomar no post-it para calcular a duração do projecto. Você criou uma rede lógica que o vai ajudar a entender as dependências no projecto, o calendário e o fluxo de trabalho. Esta técnica pode revelar informações importantes que poderiam ser negligenciadas.

Milestones

Procure milestones na sua Rede Lógica. Uma milestone natural pode ocorrer a qualquer momento numa série de actividades paralelas que se reúnem num ponto. Controlar o projecto, definindo resultados concretos para cada etapa. Um resultado concreto é algo que você pode ver ou tocar como uma especificação de projecto, um protótipo, um modelo, um módulo de software.

Utilizar Software de Gestão de Projecto

As informações da WBS e da Rede Lógica podem ser de introduzidas num pacote de software como o Microsoft Project (que toda a gente usa ou julga saber usar) para criar um plano detalhado. Escreva as actividades, predecessores, recursos e estimativas de tempo no software. Uma vez introduzidas, o software irá criar as tabelas e gráficos automaticamente. Não espere pelo software para planear ou gerir o projecto, este é apenas uma ferramenta.

Lista de Verificação

Aqui está uma lista de verificação para o ajudar a criar um plano detalhado do projecto, bem pensado, enquanto se constrói uma equipa de alto desempenho e motivada.

1. Definir o que deve ser feito usando uma Work Breakdown Structure.
2. Desenvolva a melhor abordagem para obter tudo o que deve ser realizado através do desenvolvimento de uma Rede Lógica.
3. Desenvolver estimativas de trabalho e duração e de quanto tempo cada membro da equipe precisa para cada tarefa.
4. Calcular quanto tempo o projecto levará para completar o seu caminho crítico e milestones com a utilização da Rede Lógica.
5. Calcular e mapear o número de pessoas necessárias e a percentagem de tempo que cada membro da equipa usa em cada fase do projecto.
6. Ajustar e refinar o plano de projecto para cargas de trabalho de nível individual e adapte o número de pessoas necessárias durante o projecto.
7. Optimizar criativamente os trade-offs para entregar os melhores resultados no menor tempo.
8. Use o processo de planeamento combinado para intensificar o compromisso dos membros da equipe e a propriedade distribuída do projecto.

Texto de Duncan Haughey, PMP, traduzido por Luís Quintino

Gestão de Tempo num ambiente multi-projecto

Estou preocupado por que continua a haver pessoas que pensam que há aí no mercado o software de gestão de tempo perfeito que irá conseguir resolver os problemas dos seus planos. Na verdade este é um desafio que não pode ser ultrapassado só por tecnologia, pois há aspectos dos hábitos que jogam aqui, para além da natureza própria do desenvolvimento de software.

O manual do PRINCE2 declara que um membro da equipa só consegue realizar 3,5 dias de trabalho produtivo numa semana (no máximo)[i]. Outras actividades tais como reuniões, falar ao telefone, ir a uma festa da empresa, etc. ocupam todo o tempo remanescente.

A lei de Parkinson declara que as pessoas irão usar todo o tempo que têm para realizar uma actividade (por exemplo, para arrumar 1000 revistas são necessárias 2 horas, mas se dermos a uma pessoa 4 horas para isso, irá levar 4 horas). Mas esta noção é muitas vezes interpretada como poder sempre obter mais das pessoas se os espremermos, coloca-los sob pressão, dar-lhes prazos impossíveis de cumprir. Claro que isto pode permitir obter ganhos de curto prazo, mas o mais provável é resultar em desencorajamento das pessoas e diminuição de resultados.

Se pretendemos aumentar a produtividade, certamente existem outras formas possíveis de o alcançar.

Sabemos que um projecto está a trabalhar bem, quando os membros da equipa só colocam questões de dois em dois ou de três em três dias. O que significa que eles sabem o que fazer a seguir e não perdem o ritmo.

Muitas vezes, a deficiente gestão de tempo não decorre de mau agendamento, antes é uma questão que decorre da gestão de projecto. O gestor de projecto é responsável pela decisão das prioridades e não os membros da equipa ou os gestores de recursos. Aqui é que está o problema real, quando a gestão atribui prioridades sem compreender o peso e o efeito em outros projectos. Como a história da manta pequena e dos pés ou dos ombros alternadamente a descoberto. As pessoas preocupam-se demais com as datas de entrega quando deveriam enfrentar o desbaratar de tempo resultante da má optimização das práticas de planeamento.

Devemos ser realistas acerca da disponibilidade dos recursos. Temos de prever a realização de actividade em feriados e os tempos gastos em actividades fora do projecto ou não previstos. A semana de trabalho média é de 4 dias depois de se retirarem estes tempos. Destes quatro dias, pelo menos meio dia será gasto em outros deveres, como reuniões, actividades de gestão e de acompanhamento de outros projectos.

---

[i] Página 181. Managing Successful Projects with PRINCE2 (3rd Ed.)

A agenda da reunião do PMO

Muitas empresas realizaram investimentos para implementarem processos e ferramentas de PMO e lutaram e lutam constantemente para alcançarem alguns dos benefícios que este lhes deveria trazer. A criação de práticas regulares de revisão e colaboração são um dos meios para consistentemente chegarmos a resultados. É essencial que os participantes no processo estabeleçam regularidade na aplicação de métodos e práticas de trabalho. A reunião semanal do PMO é uma dessas ferramentas.

Os quatro tópicos principais para a agenda deveriam ser:

• Revisão de novas boas práticas
• Revisão de novos projectos
• Avaliação de Alto Risco
• Revisão dos Agendamentos em Implementação

 
A revisão das novas Boas Práticas

A revisão das novas Boas Práticas consistirá na análise das boas práticas já implementadas nas semanas anteriores. Estas serão baseadas nas Lições aprendidas de projectos que se aproximam da fase final. Pode consistir em qualquer coisa desde um novo processo de aprovação a um workflow de trabalho até a uma forma diferente de trabalho com os clientes. Realizar-se-á uma discussão mínima visto os detalhes já terem sido abordados antes da realização da reunião, e é realizada uma apresentação do tipo «esta é a forma como agora iremos operar».

 
A Revisão de Novos Projectos

Permite que aqueles que pretendam iniciar um novo projecto o apresentem em sumário ao PMO (no máximo com uma descrição de 1 página), incluindo os objectivos de negócio e os benefícios que o novo projecto trarão à organização. Abre-se de seguida um período para questões e respostas. O projecto seguirá para os passos seguintes de aprovação executiva ou colocado para mais pesquisa e aprofundamento com o negócio. O que incluirá a sua referência nas próximas reuniões do PMO.

 
A parte de Avaliação de Alto Risco

Compreende a análise de um relatório das milestones de alto nível dos projectos que mostram com «semáforos» a Vermelho, Amarelo e Verde os status de todos os projectos dentro da organização, filtrados por unidade de negócio. Não se irá perder tempo com o que está a correr conforme o plano, antes, com base numa gestão por excepção, o foco será só nos projectos que estão com dificuldades. Serão tomadas decisões para estes projectos, os obstáculos levantados e os riscos mitigados.

 
A parte final da reunião

O period final da reunião será a Revisão dos Agendamentos em Implementação, para rever as actividades de implementação final que deverão ter cuidados especiais e utilizar períodos específicos do dia. Estas actividades dada o alto pendor crítico recebem o acompanhamento num plano específico e especial atenção será dada a actividades previstas para a próxima semana.

Para que uma reunião de PMO tenha sucesso importa garantir a presença das pessoas certas, que possam (tenham a autoridade para) tomar as decisões no momento. Se durante a reunião alguém pensar «temos de ver isto com..», então não temos as pessoas certas na sala.

Desta forma, com uma hora por semana, conseguimos crescer no nosso nível de profissionalismo, rever e aprovar novos projectos, mitigar o risco e trazer toda a gente para o nível de conhecimento sobre os projectos.

LQ

Delegação de actividades em Projecto

O sucesso na delegação de actividades é essencial para o êxito na gestão de projecto. Contudo, muitas das pessoas envolvidas como líderes em gestão de projecto têm medo da delegação. Eles receiam que, se delegarem, o trabalho não seja correctamente realizado, que os prazos não sejam alcançados. Eles não confiam na colaboração e no trabalho de equipa e habituaram-se a fazer a maioria das coisas e controlarem directamente tudo o resto.
Mas o problema está na forma como fazemos a delegação – esta tem de ser feita de forma efectiva. A gestão de projectos depende simplesmente da delegação por força da lei da divisão do trabalho: uma pessoa ou equipa focada em uma ou duas actividades específicas é mais eficiente e produtiva que uma pessoa que tenta realizar simultaneamente uma multitude de actividades. Uma pessoa não pode ser todas as coisas para um projecto ou um negócio. Se a delegação for feita de forma adequada com facilidade se conclui que quanto mais de fizer o «laissez faire» em gestão de projecto melhor. No fundo que o melhor gestor é o que gere menos.
O sucesso da gestão de projecto depende da colaboração e do trabalho de equipa e a delegação bem-feita faz com que estes elementos em surjam com sucesso. Quais os cuidados que devemos ter para delegar quando gerimos um projecto?
Não seja vago – se está a gerir um projecto e se vai delegar actividades, deve ser bastante específico acerca do que se espera realizar com a actividade, quando é que deve ser realizado e o que se espera pela realização da actividade. As descrições vagas conduzem a resultados duvidosos e à falha em cumprir os prazos.
Garanta que estabelece prazos realistas – os prazos devem ser realistas e executáveis dentro do tempo pelas pessoas seleccionadas para a actividade. Obviamente, que a delegação envolve escolher as pessoas certas para as actividades certas de acordo com os seus talentos e competências, mas deve ainda assegurar-se que as pessoas que vão ser atribuídas às actividades não terão conflitos ou problemas de agendamento.
Fornecer toda a informação necessária a cada delegação – forneça aos que receberam a delegação uma direcção para alcançarem os recursos que possam ser necessários para os tornar mais aptos a concluírem o trabalho em tempo. A colaboração e o trabalho de equipa podem estra entre estes recursos.
Garanta que está disponível como líder da gestão do projecto – os seus delegados devem ser capazes de lhe colocar quaisquer questões ou preocupações acerca do projecto ou das suas actividades. Adicionalmente, deve garantir que eles prestam contas o que exige relatórios periódicos. Contudo, não pressione demais. Um relatório semanal de status deve ser suficiente, desde que o projecto leve mais de uma semana a completar.
Está assumido que se delega actividades em gestão de projecto porque não temos tempo para fazer tudo por nós – Pode até ser que estejamos tão afogados que seja difícil dar instruções explícitas para as actividades. Se é este o caso, deve assegurar-se de delegar numa pessoa como o contacto directo e o gestor do projecto. Será responsabilidade desta pessoa ser o seu «braço direito» e quem terá a responsabilidade de fornecer as especificidades para os outros envolvidos para que possa haver êxito na colaboração e trabalho de equipa. Algumas vezes até a coordenação de uma parte de um projecto deve ser delegada. Se tal ocorrer, tenha o cuidado de realizar a delegação para alguém com experiência de gestão de projectos ou no tipo de trabalho que o projecto irá realizar.
Depois de ter delegado, lembre-se de manter as mãos fora do trabalho o mais possível – Permite aos que estão empenhados um espaço criativo no projecto. Deixe-os aparecer com as suas ideias próprias e fazer mesmo sugestões na forma de fazer as coisas melhor. O fundamental é que se obtenha os resultados desejados e o objectivo do projecto. Claro que a palavra final é sua na aprovação das mudanças às coisas, mas, ao mesmo tempo, não há necessidade de ser autoritário.
Para além dos relatórios de status mensais, implemente um processo de relatórios sobre o projecto – É muito importante ter acesso constante a informação sobre a forma como estão a realizar-se as coisas. Faça isto mas monte um sistema com pro-actividade em que as pessoas envolvidas no projecto se sintam confortáveis a actualizar os registos sem necessidade de marcar uma reunião.
Mantenha um registo pessoal sobre quem está a fazer e que actividade – registe todos os relatórios de status e detalhes de progresso. A manutenção destes registos mantém o seu pensamento sobre o projecto e garante uma dupla verificação dos seus detalhes.
Não se esqueça de louvar e mostrar o crédito quando as actividades são concluídas bem e em tempo ou quando se regista um bom progresso na actividade – os membros da equipa precisam de receber um feedback positivo quando estão a fazer as coisas certas. Não só merecem isso como esse reconhecimento ajuda-os a manter o foco, mantém-nos motivados e ajuda-os a compreender o que devem fazer.
Estes são alguns cuidados a ter quando delegamos actividades em gestão de projecto. A delegação não é uma coisa simples. Exige consideração, compreensão dos requisitos de projecto e um entendimento das capacidades e competências dos que colaboram connosco
O trabalho de equipa e a colaboração conseguem-se se for feita uma delegação correcta desde o início. Através da delegação conseguimos guiar um projecto até aos seus resultados desejados, sem dores de cabeça, sem excesso de micro-gestão e com todos os envolvidos muito mais contentes e o projecto alcança o que todos desejam – o sucesso.

Como impressionar com uma Apresentação

Os gestores de projecto têm de ser capazes de apresentar o seu trabalho, tal como as conclusões da análise das questões presentes, as alterações propostas e o status das realizações e projectos em curso. Se pesquisar no Google por apresentação executiva, por exemplo, vai obter um monte de links mas muitas vezes os recursos obtidos estão focados em como preparar ou como se comportar durante a apresentação. Há outro aspecto importante que é: o que é que deve estar contido na apresentação e como deve ser organizado o conteúdo?

Iniciar o projecto

Tente limitar o sumário ou visão geral a UM slide

Os executivos de empresas têm muito pouco tempo para entrar em detalhes dos projectos, assim a abordagem correcta é sumarizar o projecto exactamente num único slide. Este slide deve fornecer uma visão geral dos pontos-chave de relance. Como este pode ser o único slide para o qual terá tempo para apresentar deve ser sucinto e directo. Ao concentrar-se neste slide singular deve focar-se em apresentar só a informação essencial. Frases curtas. Em vez de pontos são muito melhores, especialmente se a apresentação seja distribuída posteriormente e entregue aqueles que não puderam estar presentes. Poderá sempre entrar em detalhes durante o resto da apresentação, mas este slide deve valer por si.

Utilize metáforas

A mente humana adora metáforas, especialmente as mais curiosas. Eu uso uma de uma estrada com distância entre cidades para preparar as pessoas para uma abordagem faseada que se move do estado presente com os seus pontos quentes para uma meta. Deve usar aquilo que for apropriado para a visualização dos participantes e do projecto.

Dê uma direcção

Para obter a atenção das pessoas pode usar a transição de estados das diversas fases com a base da apresentação dos slides. Importa definir as questões mais importantes, alinhar a transição de fase com os objectivos de negócio da empresa e desenhar o estado futuro almejado pela meta definida. As pessoas serão assim capazes de se situarem.

Anuncie pontos de paragem

conforme a natureza da mensagem, pode dividir a estrada em diversos segmentos com pontos de paragem que definem as fases. Estes pontos de paragem são portões que serão utilizados para avaliar os resultados da fase concluída antes de tomar decisões para avançar para a fase seguinte e quanto tempo irá ser necessário para a realizar, a que custo e quais os riscos conhecidos, que alterações se prevêem, e depois salientar as realizações esperadas para manter todos motivados.

Enfrente os riscos

Contudo a imagem que damos não pode ser completamente idílica. Não há acções sem riscos e então é melhor identificar os riscos desde o início. Os participantes vão adicionar mais uns quantos através das suas dúvidas, discussões e questões e deve assegurar-se que os anota. Faça o possível por anotar a importância da identificação e mitigação dos riscos como um importante processo que continua durante todo o projecto.

Mostre os custos em relação com as poupanças

Não há refeições grátis. Utilize essa ideia para manter os participantes com o pensamento naquilo que importa. Quando se apresentam estimativas de custo é importante mencionar poupanças e/ou benefícios mesmo quando são só potenciais. A chave está em que se ponderou sobre este aspecto de negócio do projecto. Lembre-se que a qualquer estimativa inicial de custo, mesmo quando se sublinha «estimativa», será registada e infelizmente nunca será esquecida.

Conclua com um sumário

No fim da apresentação, sumarize rapidamente as etapas e as realizações chave, os custos projectados, as poupanças esperadas, as mudanças ao estado presente e como irá apresentar-se a meta estabelecida no futuro.

LQ

Plano do Projecto – como escrever um plano vencedor

O Plano do Projecto é um dos documentos mais importantes e úteis na sua caixa de ferramentas e deve ser permanentemente acompanhado e actualizado durante a vida do projecto. O seu propósito inicial é o lançar o projecto convencendo os decisores (aqueles que controlam o financiamento, por exemplo, o Board do Projecto ou o comité de pilotagem) que o projecto é viável e que irá atingir as necessidades previstas dentro da escala de tempo definida, cumprindo o orçamento e atingindo as expectativas.

Se o plano do projecto está escrito de forma incompleta ou deficiente, o projecto pode nem sequer passar a primeira decisão e pode nem arrancar. Muitos projectos viáveis ficaram neste estágio devido a deficiente planeamento e pobre comunicação. No lado positivo, pode realizar um grande plano do projecto, que estabelece a sua credibilidade como gestor de projecto, inicia com solidez o projecto e fornece à equipa de projecto como um mandato para a acção e uma direcção clara a seguir.

Não deve confundir um plano de projecto com um agendamento de projecto (schedule). Um agendamento é somente um elemento do plano do projecto e toma a forma de uma linha de tempo ou gráfico de Gantt ligando as actividades à linha de tempo. O agendamento do projecto é uma ferramenta vital e deve complementar o plano de projecto Os grandes planos de projecto contém diversos agendamentos normalmente como apêndices, que são referidos ao longo do documento. Estes agendamentos devem incluir a escala de tempo total, um agendamento para teste, um agendamento de implementação, a análise do caminho crítico, um agendamento de atribuição de recursos, etc.

O que deverá ser incluído no Plano do Projecto?

O Plano do Projecto serve como um mapa das estradas para a equipa de projecto e oferece orientação na prioridade das actividades, o âmbito do trabalho, as metodologias e a governação que será usada, quem são os stakeholders, qual a abordagem global a adoptar, como serão geridos os custos e as pessoas, quais os standards de qualidade do projecto, como é que o projecto irá comunicar com os stakeholders, como será medida a performance e os benefícios, etc.

As principais áreas que devem ser cobertas no plano incluem:

• Background do projecto
• Objectivos
• Âmbito
• Constrangimentos
• Assumpções
• Dependências e impactos
• Questões e riscos
• Metodologia e estratégia
• Controlos; âmbito, tempo, custo, qualidade, recursos
• Comunicações
• Agendamento da realização
• Medida de performance
• Realização dos benefícios

Como vê existem muitos elementos num plano de projecto e alguns dos maiores planos podem atingir mais de 100 páginas em extensão. Esta característica faz com que a seja muito importante a estruturação do documento. Um formato consistente com uma ordem lógica e títulos claros irá permitir aos leitores navegar rapidamente através do documento e obter os detalhes que são importantes.

Tente nunca omitir nenhuma das áreas críticas que referimos acima, porque isso pode comprometer a decisão ou exigir mais custos no futuro se ocorrer uma incompreensão. Por exemplo, se não se conseguir identificar correctamente o que está fora do âmbito do projecto, podemos vir a ter uma disputa durante a sua execução. Ou pode acontecer que sente que o projecto está a realizar um produto que julga satisfatório, mas que falha na consecução das expectativas do cliente porque têm critérios diferentes de qualidade. Estas não são situações em que se queira ver envolvido e podem ser facilmente evitadas se escrever um plano detalhado e completo.

Quanto mais informação relevante e detalhada incluir no plano nesta fase inicial melhor, mas deve sublinhar relevante. Evite a tentação de incluir no seu documento parágrafos desnecessários e tente não se repetir. Se necessitar sublinhar um ponto, refira essa secção num índice (usando títulos) em vez de repetir toda uma secção. Utilize as referências para dar ênfase a questões que devem estar presentes para o leitor. Este agradecerá esta atenção e, ao mesmo tempo, fará com que seja mais fácil editar o documento. Claro que atingir o nível adequado de detalhe é difícil e só pela experiência irá ficar mais habituado a isso. Depois de ter escrito alguns planos de projecto saberá como adaptar cada um de acordo com a dimensão do projecto e as expectativas da sua audiência. Como fazer isso?

Adaptar à audiência

O plano do projecto é muitas vezes dos primeiros pontos de referência para os stakeholders, sejam novos membros da equipa, executivos, clientes, utilizadores, fornecedores e outras partes interessadas. Assim, quando escreve o plano deve ter na mente que este deve estar adaptado para tal ampla audiência e deve poder ser lido por alguém que não tenha um conhecimento prévio do projecto. Garanta sempre que introduz o contexto do projecto e oferece alguma informação anterior e história sobre aquilo de que se fala. Inclua um glossário ou termos de referência para explicar as abreviaturas e acrónimos. Quando se referir a outros documentos pode ser útil incluir detalhes nos apêndices para benefício das pessoas que não tenham lido antes esses documentos.

Não é o Processo que Falha na Realização durante a crise

Devemos compreender que, durante uma crise, não é o processo que falha. O fracasso é causado por uma sobre confiança num processo excessivamente prescritivo. Neste esforço para adoptar disciplina e rigor de processos, as organizações de TI adoptam muitas vezes uma abordagem de desenho de processos muito prescritiva. O desafio é que quanto mais prescritivo é um processo, mais complexo este se torna. Se tenta responder a muito pequenas acções então vai ter de avaliar todas as acções possíveis. A complexidade consequentemente limita a sua capacidade.

Muito embora um processo altamente complexo e prescritivo possa funcionar num ambiente muito previsível, este não é, no entanto, o ambiente normalmente encontrado pelas organizações de TI.

Mas, se estes são os processos altamente prescritivos e complexos que a organização de TI implementou, então quando ocorre uma crise, a taxa e volume de actividade simplesmente submerge a capacidade deste processo altamente prescritivo. Mas, sublinha-se, não é o processo que falha. Se o processo tivesse sido construído dentro da assumpção que os seus executores não necessitavam daquele alto nível de prescrição, poderia ser suficientemente simples pra ser escalado e enfrentar o volume que a crise gerou.

Isto conduz-nos ao cerne do problema: as organizações de TI constroem processos altamente prescritivos e complexos porque não confiam nas competências de liderança e criatividade dos seus executores.

Criar Competências de Liderança e Criatividade

É essa diferença na confiança que conduz ao fracasso do processo durante a crise. Ironicamente, a falta das competências de liderança e criatividade que conduzem a um processo demasiado prescritivo são também as duas mais importantes competências necessárias para gerir com efectividade durante uma crise. O desenvolvimento destas duas competências não só irá permitir a construção de processos que não se baseiam em elementos demasiado prescritivos, mas fornecerão à organização as capacidades que esta necessita para poder responder durante uma crise.

A criação destas competências de liderança e criatividade assenta nas seguintes três bases fundamentais:

• Desenvolver o propósito operacional
• Embeber o valor do Negócio como a base para o paradigma de decisão
• Criar uma cultura de responsabilidade e aptidão.

Porque falham os processos numa crise

A tecnologia é um componente crítico de todos os negócios. Durante uma crise, se a organização de TI é incapaz de responder pode por toda a companhia em risco. Entretanto, durante uma crise aquilo que muitas vezes inibe uma organização de TI de responder com efectividade é exactamente a mesma coisa que a deveria salvaguardar – a confiança em processos disciplinados.

O problema fundamental é que a introdução das disciplinas de processo na gestão operacional de TI, na última década, criou uma atmosfera em que a gestão intermédia de TI fica muitas vezes com medo de tomar decisões e falta-lhes competências de criatividade e liderança. Contudo, durante uma crise, o que é mais exigido antes de tudo mais são essas duas competências.

Embora uma organização de TI possa funcionar admiravelmente sob operação normal, muito poucas organizações conseguiram alcançar uma maturidade tal nas suas disciplinas de processo que sejam capazes de responder efectivamente a interrupções massivas de serviço e negócio. Podem ter protocolos em posição para disaster recovery, mas do ponto de vista operacional os seus processos ficam submergidos durante uma crise devido ao enorme volume e velocidade das exigências operacionais que lhes são requeridas. É neste ponto que os processos fracassam e a organização de TI cai num estado de caos não gerido. É também neste ponto que certos membros da equipa de TI se «destacam» e «fazem tudo o necessário» para resolver as coisas – fazendo ressaltar a cultura de cowboy contra a qual as organizações de TI batalharam durante anos.

Para ultrapassar estes desafios, a gestão de TI deve investir no desenvolvimento das competências quer de liderança quer de resolução criativa de problemas a todos os níveis da organização. Estes dois atributos são exigidos não só na gestão sénior mas também a todos os níveis da organização. Durante uma crise, as equipas de TI podem ficar isoladas, sem modelos claros de decisão e dispondo de pouca informação. Elas devem então ser capazes de se auto organizarem, avaliarem a situação, estabelecerem linhas de comunicação e assumirem as funções de liderança de forma dinâmica.

Luís Quintino

Body Language

Usar e interpretar a linguagem corporal é uma ferramenta muito importante e que é determinante no trabalho. Apresento algumas técnicas para utilizar esta ferramenta.

A regra dos 30 segundos

Uma opinião é feita acerca de você nos primeiros 3º segundos de contacto com alguém, assim é importante desempenhar o papel que queremos vender. Se pensa ser criativo então vista-se de escuro. Cuidado, as mulheres olham sempre para os sapatos, então garanta que estão limpos.

Atenção ao Aperto de Mão

Os apertos de mão oferecem uma visão do carácter da pessoa. Esta percepção não é nem boa nem má, antes oferece informação em como definir objectivos quando se relacionar com a outra pessoa.

Manter o contacto ocular

Esta é uma indicação para a outra pessoa que ele ou ela são suficientemente importantes para conquistarem a sua atenção. Senão fizer isso está a evidenciar uma apreciação negativa. Durante apresentações, mentalmente divida a sala e faça contacto com cada parte da sala. Criará, desta forma, o efeito que está a falar directamente para cada indivíduo presente na sala, criando assim ligações com cada pessoa.

Seja consistente com aquilo que diz e com o que faz

Muitas vezes as pessoas procuram inconsistências numa pessoa para avaliarem se ela é de confiança; assim, é importante certificar-se que à consistência com a sua marca. Se diz que está entusiasmado com alguma coisa, garanta que a sua face, corpo e voz exprimam entusiasmo. Será que alguém que acabou de ganhar 10 milhões pode dizer isso de forma monótona?

Remova obstáculos

Quando procurar estabelecer relações, esteja consciente da linguagem física e corporal que pode estar a transmitir e a criar barreiras. Por exemplo, cruzar os braços e as pernas ou posicionando-se atrás de uma cadeira ou secretária são duas formas de se bloquear da ligação à sua audiência. As pessoas querem sentir-se ligados e quando se removem barreiras físicas entre si e outra pessoa está a criar uma atmosfera mais aberta na qual ambos se sentirão mais à vontade.

Luis Quintino

Passos para uma melhor Governação

Melhorar a governação nas organizações é um processo de mudança estratégica. A Governação não é só um processo novo mas é algo que também necessita de uma nova cultura e comportamento nos níveis seniores quer das TI como do negócio. Os centros de poder estabelecidos nas organizações nem sempre aceitam de bom grado a transparência e responsabilidade. A experiência sugere que um forte apoio do CEO e CIO e um crescimento gradual da maturidade da governação dá melhores resultados do que ajustes constantes.

Como ajuda, eis aqui 10 passos para melhorar a governação de TI.

1. O compromisso visível e activo da gestão de topo é absolutamente crítico para o sucesso de qualquer iniciativa de governação. A governação é uma abordagem disciplinada. Terá de haver consequências da não conformidade para todos os executivos.

2. Trate da governação como de um programa de mudança que requer recursos e compromisso. Terá de ter benefícios visíveis para que se considere que obteve sucesso. Considere, ainda, a cultura da organização, os recursos disponíveis e a capacidade para a mudança. Estabeleça objectivos credíveis, meça e comunique os benefícios.

Se as TI estão a trabalhar para oferecerem um serviço de confiança ou têm um registo histórico pobre no que respeita a serviço ao cliente ou realização de projecto, deve focar os esforços de governação para enfrentar estas questões candentes em vez de nobres objectivos de alinhamento estratégico e outros similares.

3. Utilize frameworks conhecidas para a iniciativa de governação. Há várias como a COBIT, ITIL e outras.

4. O poder da governação vem da transparência na tomada de decisão e no reporting. A transparência quer seja em business cases. Conformidade com os standards ou relatórios de saúde de projectos, cria a confiança e cria uma pressão para enfrentar as questões identificadas ou para questionar decisões não usuais.

5. Deve criar um processo formal para registar e tratar das excepções. Em seguida relate a percentagem de excepções e a sua razão. Pode ser que o standard seja inapropriado ou que o incumprimento seja pobre. Discuta abertamente e enfrente.

6. Encoraje o consenso do grupo de pares a cada nível da camada de governação e evite a escalação de conflitos para níveos mais elevados. Esta atitude irá criar confiança e sentido de compromisso em relação à estrutura de boa governação.

7. Quando possível alinhe a governação das TI com os mecanismos de governação corporativa. A maioria das companhias têm, com mais ou menos maturidade, mecanismos gestão de risco, gestão de investimento, gestão de crises e de continuidade. Aline as TI com eles quando possível.

8. Eduque a gestão sénior nos benefícios da Governação das TI bem como em novas tecnologias e desafios para que possam participar de maneira informada nas decisões chave relacionadas com tecnologia. A falta de conhecimento tecnológico não deve ser uma desculpa para os executivos não participarem nas decisões chave de investimento tecnológico.

9. Construa a prestação de contas da realização dos benefícios dentro do próprio business case. O que irá encorajar um interesse activo na governação da realização.

10. Evite entupir o comité de pilotagem das TI com detalhes técnicos ou da arquitectura. Trate das questões e detalhes técnicos num fórum técnico e reporte só sobre a conformidade ou não conformidade/risco à equipa de topo. O board pode assim concentrar-se em saber se «é esta a coisa certa para fazer ou investir» em vez do «como».

Modelos de Governação de TI

Não há uma definição que sirva todos os modelos para a governação de TI.

Os três modelos comuns são baseados nos três estilos de tomada de decisão das organizações. Estes são: centralizada, federada ou descentralizada.

No modelo centralizado é enfatizada a eficiência e o controlo de custos relativamente à responsabilidade das unidades de negócio. Há um interesse grande nos standards, sinergias e economias de escala.

No modelo descentralizado há uma grande propriedade do negócio da unidade e responsabilidade, mas a integração e as sinergias sofrem o que resulta em prováveis custos mais altos.

O modelo federado tenta combinar as melhores funcionalidades dos dois anteriores. As aplicações comuns e os recursos de infra-estrutura são partilhados, enquanto as unidades de negócio controlam as respectivas aplicações específicas.

Características de uma boa Governação de TI

¶ Os investimentos e as decisões de TI são avaliados de forma similar aos investimentos de negócio e as TI são geridas como um activo estratégico. Isto significa que há a participação da gestão de topo nas decisões chave de TI. Existe uma orientação do board para os investimentos de TI e executivos que são responsáveis e prestam as contas da realização dos benefícios.

¶ As TI são uma parte essencial do planeamento corporativo e do planeamento estratégico. As TI compreendem as dinâmicas de negócio e contribuem para o desenvolvimento da estratégia do negócio, que está interligada com a estratégia de TI. As TI e o negócio trabalham em conjunto para identificar oportunidades.

¶ Os principais riscos de TI são considerados de forma integrada dentro da estrutura de gestão de risco corporativa. Os riscos como os de protecção de dados, segurança de TI e continuidade de negócio merecem uma revisão periódica por parte do board.

¶ A performance das TI é medida regularmente e comparada com os seus pares e as boas práticas do mercado.

¶ Como e porque são tomadas as decisões é claramente entendido e os resultados são clara e formalmente comunicadas aos stakeholders. Os processos de excepção formal estão estabelecidos e promovem a transparência bem como permitem a aprendizagem organizacional.

As 4 Perguntas da Governação

Conforme as organizações do sector público e privado estão cada vez mais dependentes das TI, também começa a existir um crescente reconhecimento da necessidade de governação das TI como uma parte essencial da mais ampla governação das organizações. A Governação é tudo acerca de quem toma as decisões, como são estas decisões formadas e quem tem de prestar contas delas.

Muitos dos executivos de topo ainda consideram as TI como muito complexas, técnicas e difíceis de governar. A governação de TI continua, muitas vezes só nas grandes organizações, a ser percebida comi uma coisa do CIO (Chief Information Officer) e desta forma a governação do negócio continua a ser fraca.

As 4 perguntas da governação

A governação das TI visa garantir que os recursos da organização são usados da forma certa para criarem valor enquanto gerem os riscos das TI. A framework Val-IT do IT Governance Institute trata destes desafios. Esta é uma sólida estrutura de conhecimentos que ajuda que os esforços das organizações sejam alinhados e que as TI continuem a entregar valor para o negócio.

1. Será que estamos a fazer coisas certas? Peter Drucker disse “Não há nada tão inútil como fazer eficientemente as coisas que não deveriam nunca ser feitas”. Esta é a pergunta sobre se deveríamos fazer de todo tal coisa. Garante assim o alinhamento estratégico entre o negócio e as TI. Aquilo que estamos a pretender fazer encaixa dentro da visão e estratégia da organização? Será que é consistente com os princípios de negócio?

2. Estaremos a fazê-lo da forma correcta? Esta é a pergunta que trata da arquitectura e dos standards. O que estamos a fazer está conforme com a arquitectura e os processos?

3. Estamos a realizá-lo bem? Esta é a questão sobre a execução. Será que possuímos processos para a realização disciplinada e para a gestão da mudança? Possuímos os recursos com as capacidades especializadas correctas e estaremos a geri-los adequadamente? Como medimos a nossa performance relativamente a outros? Estamos a gerir com efectividade os riscos?

4. Estamos a obter os benefícios? Esta é a pergunta da realização do valor dos investimentos / projectos de TI. Temos um claro consenso acerca deles? Possuímos as métricas para os avaliar? A Responsabilidade pelos benefícios está claramente definida?

Estas 4 questões cobrem o cerne da governação, que é constituído por: Alinhamento Estratégico, Realização de Valor das TI, Gestão de Risco das TI, Gestão da Performance e Gestão de Recursos de TI. Quando os gestores em todos os níveis tratarem destas questões será quando a Governação de TI fará parte da cultura.

Desenhar Objectivos SMART

A cultura anglo-saxónica habituou-nos à utilização de acrónimos e frases que funcionam como mnemónicas mentais para fazer as coisas da forma entendida como a mais adequada. Um desses é o SMART.

O acrónimo SMART é uma ferramenta para nos assegurarmos que os nossos objectivos e instruções são Específicos (S). Mensuráveis (M), Atingíveis (A), Relevantes (R) e em Tempo (T). Ajuda na clarificação do que pretendemos alcançar e estabelecer os prazos para ficarmos certos que iremos produzir os resultados que queremos dentro da escala de tempo que necessitamos.

1º Passo – Avalie as suas intenções

Antes de começar a afinar os seus objectivos, lembre-se de reverificar a sua intenção para querer alcançar este objectivo. Pergunte-se a si próprio:

• Qual é o resultado final que quero alcançar?
• Porque é que isto é tão importante para mim e para a minha organização?
• Se não alcançar este objectivo ou o fizer deficientemente, como é que isso irá afectar a minha carreira / planos de vida, auto-estima ou realização no trabalho?
  

2º Passo – Torne-os Específicos

Se a sua descrição de objectivos é inequivocamente clara para aqueles que a lêem, está à procura de confusão e de uma desculpa. Depois de ter escrito o objectivo pergunte-se a si próprio:

• Se alguém ler este objectivo, será que conseguirá executá-lo sem me ter a mim para o explicar?
• Será que o objectivo fornece as respostas ao Quem? Quê? Quando? e Onde?
• Está curto e conciso?
  

3º Passo – Torne-o Mensurável?

Já ouviu dizer, provavelmente, que «O que pode ser medido, pode ser feito.» Quando se desenham declarações de objectivos que são mensuráveis, estamos muito mais perto de as fazer e sabemos que as alcançámos porque produzem resultados claros. Para se assegurar que os seus objectivos obtém resultados, pergunte-se:

• Como saberei se este objectivo ou milestone foi alcançado e até que ponto?
• Como é que o irei medir e com que frequência?
• É totalmente claro para os que são parte da realização deste objectivo quais são os resultados mensuráveis?
  

4º Passo – Tornar os Objectivos Alcançáveis

Até pode querer, na próxima semana, ter uma promoção no trabalho ou até começar uma viagem à volt do mundo por um ano. Embora estes objectivos sejam excitantes e possíveis, eles podem não ser atingíveis para já. Pergunte-se:

• Pode este objectivo ser atingido (mesmo com algum esforço) dentro da escala de tempo indicada? Se não, divida o objectivo em partes mais pequenas e escreva de novo a declaração de objectivo.
• Se não consigo alcançar este objectivo dentro da escala de tempo indicada, quais são as mudanças que devo fazer para o conseguir?
  

5º Passo – Torne-o Relevante

Se os objectivos não parecem relevantes temos a tendência de os pôr na estufa. De facto, há sempre demasiadas outras coisas em que nos focarmos e para fazermos. Para garantir que os objectivos são relevantes, pergunte-se:

• Como é que este objectivo de alinha com a imagem total?
• Que problemas poderão surgir se não conseguir concluir este objectivo?
• É mesmo neste ano ou mês que este objectivo deve ser concretizado?
  

6º Passo – Fazer em Tempo

Muitos objectivos falham porque não identificamos a linha de tempo dentro da qual os queremos realizar. Para aqueles de nós que somos recorrentes em não fornecer escalas de tempo mensuráveis, parece-nos que os mesmos objectivos aparecem vezes e vezes repetidas nas nossas folhas de planeamento: para prevenir quer isto aconteça, pergunte-se:

• Será que estabeleci um prazo final global para a realização deste objectivo?
• Indiquei as milestones ou outros prazos para as actividades que contribuem para o progresso?
• Quando é que quero isto concretizado?

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

Cinco competências de Comunicação

Liderar Pessoas – a parte prática da gestão de projecto – é tão importante como as competências para as actividades.

A comunicação é uma competência crítica para o sucesso do projecto porque mantém os membros da equipa actualizados e porque ganha o apoio dos stakeholders chave.

Mas quais as competências que fazem a diferença? Eis a opinião de muitos dos gestores de projecto.

1. Escuta activa

Esta é a nossa capacidade para ouvir e compreender os outros. Ouvir as palavras e o significado por detrás das palavras, não interromper ou deixar a nossa mente vaguear, colocar perguntas para garantir a compreensão, observar os sinais não-verbais.

2. Construir relações com base no respeito e confiança

A confiança e o respeito são as pedras angulares das relações pessoais. São conquistadas e não são um direito, decorrem da experiência com a sua honestidade, integridade e competência.

Entre as características que as pessoas usam para determinar a nossa credibilidade estão a honestidade, transparência, vontade de compartilhar ideias e informações livremente, a consistência, confiabilidade, lealdade, capacidade e competência.

3. Definir prioridades claras

Em terceiro lugar, está a capacidade de um gestor de projecto de transmitir a estratégia à sua equipa – através do estabelecimento de metas, planeamento e priorização. Isto é o quê, o quem, o quando, o onde, o porquê e o como do projecto. Os membros da equipa devem compreender quer o plano geral como as prioridades técnicas de baixo nível.

4. Favorecer a colaboração

Num ambiente colaborativo os membros da equipa apoiam e encorajam-se uns aos outros em vez de se focarem unicamente nas suas actividades e responsabilidades.

Eles estão dispostos a cooperar e partilhar informações, ideias e recursos para ajudarem-se uns aos outros. O resultado, assim, pode ser maior que a soma de suas partes.

5. Liderar a visão da organização

Clarificar o plano geral ajuda os membros da equipa a compreender onde se encaixa o projecto os propósitos globais da unidade de negócio e da organização. Os executivos seniores estão focados nos três pontos – finanças, ambiente, reputação – que é onde eles esperam que o seu projecto marque pela diferença.

O SCRUM essencial

O termo Desenvolvimento Iterativo e Incremental descreve uma categoria de metodologias para desenvolvimento de software em que o sistema cresce incrementalmente através de ciclos completos de desenvolvimento.

Os métodos de desenvolvimento agile de software são um grupo de metodologias iterativas específicas que combinam interacções relativamente curtas com refinação evolucionária dos requisitos, planos e metas ao longo de cada interacção subsequente.

Aparentemente as metodologias agile e iterativas tem mais baixo risco que os métodos com o estilo Waterfall, em que todo o planeamento e o desenho é feito antes do desenvolvimento.

Scrum

O SCRUM é uma das mais simples metodologias agile e provou já ser altamente efectivo para quer o desenvolvimento de software quer o desenvolvimento de produtos mais genéricos. O SCRUM é muitas vezes utilizado no desenvolvimento de produtos financeiros.

Baseia-se na ideia que durante um projecto os clientes irão com a maior das certezas mudar de ideias acerca do que querem e necessitam. Para enfrentar isto, um projecto Scrum avança numa série de interacções curtas cada uma das quais realiza um conjunto incremental de melhorias ao produto.

Scrum faz a mediação entre resultados e funcionalidades operáveis. Isto permite ao cliente receber um produto operável mais cedo e permite que o projecto mude os seus requisitos de acordo com as necessidades em mudança.

A metodologia oferece um conjunto de práticas e funções pré-definidas que são adoptadas pela equipa para maximizar as capacidades da equipa para entregar com rapidez e responder aos requisitos mudados e emergentes.

A Equipa Scrum

Uma equipa Scrum é normalmente Transfuncional e consiste em cerca de 5 a 9 pessoas, mas pode ser muito maior. A equipa tem a responsabilidade de entregar o produto. O Scrum encoraja a localização de todos os membros da equipa e a comunicação verbal entre todos.

Existem algumas funções específicas no Scrum:

O ScrumMaster

Os projectos Scrum são geridos com um estilo de gestão muito flexível e requerem gestores de projecto com experiência específica na gestão de projectos agile. A função de gestão de projecto é não tradicional, já que o ScrumMaster é, em primeiro lugar, um facilitador que institui regras acordadas, remove impedimentos ao progresso e garante que a equipa se mantém focada.

As equipas Scrum são auto-organizadas. O ScrumMaster não é o líder da equipa e actua como um buffer entre a equipa e quaisquer influências que a distraem

Proprietário do Produto

O Proprietário do Produto representa o cliente e assegura que a Equipa Scrum trabalha nas «coisas certas» numa perspectiva de negócio. O Proprietário do Produto escrever «estórias» centradas no cliente que são uma ou duas frases que em linguagem de negócio descrevem uma funcionalidade específica do produto. Estas são então implementadas pela equipa Scrum.

Stakeholders

Estas são as pessoas para quem o projecto irá produzir os resultados acordados. Eles só estão envolvidos directamente no processo durante as revisões do progresso realizado.

"Sprints" e "Backlogs"

O trabalho é compartimentado em pequenas parcelas de cerca de duas semanas de duração. Denominadas «Sprints». Durante cada Sprint, a equipa cria um incremento completo do produto tendo como resultado um produto potencialmente entregável.

O conjunto de funcionalidades que são incluídas em cada Sprint decorre de um conjunto de requisitos de alto nível do trabalho a ser feito, conhecido como «backlog do produto». Este contém descrições genéricas de todas as funcionalidades desejadas para o produto novo ou actualizado, priorizadas em termos do seu valor projectado para o negócio, bem como com estimativas do esforço necessário para as realizar.

Quais os itens específicos do backlog que são incluídos no Sprint é determinado durante uma reunião de planeamento anterior ao Sprint. Durante esta reunião, o Proprietário do Produto informa a equipa sobre os itens do Backlog do Produto que querem que sejam completados. A equipa determina então a quanto se pode comprometer durante o próximo Sprint, o que passa a ser o «backlog do Sprint» do próximo Sprint.

Durante o curso do Sprint, não é permitido a ninguém alterar o backlog do Sprint, o que significa que os requisitos estão congelados para aquele Sprint. Depois do Sprint ser concluído, a equipa demonstra o produto para o Proprietário do Produto. A equipa pode cancelar um sprint se sentir que não são capazes de alcançar os objectivos do Sprint e stakeholders externos podem também cancelar o Sprint se se manifestarem circunstâncias externas que negam o valor para proceder com este. Se um Sprint termina anormalmente, o próximo passo será conduzir uma reunião de planeamento para um novo Sprint, onde é revista a razão da terminação.

Um quadro apresentado publicamente é usado para mostrar o trabalho remanescente para o Sprint corrente. Isto é denominado um gráfico de Sprint burndown e deve ser actualizado todos os dias para oferecer visibilidade ao progresso realizado.

Transitar para o Scrum

A transição dos métodos tradicionais de trabalho para o Scrum é relativamente transparente. Pode haver benefícios em envolver um formador experimentado em Scrum para assistir na formação e implementação.

O Scrum trabalha muito bem à sua maneira é também é um excelente primeiro passo se se pretender introduzir conceitos agile na organização visto ser simples e focar-se numa gestão de projecto a alto nível.

Tradução e adaptação de artigo de Chris Young

Waterfall ou Agile: Como escolher a abordagem do desenvolvimento de Software?

Os projectos de desenvolvimento de software são normalmente abordados com a utilização alternativa de dois métodos, o Waterfall ou o Agile. Ambos têm prós e contras e cada um tem defensores que salientam o valor da sua abordagem preferida. \

Vamos analisar ambos os métodos e tentar compreender qual é o melhor e sob que circunstâncias respondem à questão: Como escolher a abordagem do meu desenvolvimento de Software?

O método de Waterfall (ou de Cascata)

O método de Waterfall já é usado desde 1970 e continua a ser o mais comum. Afirma que deve ser seguido um conjunto distinto de passos através do ciclo de vida do projecto. Os passos são usualmente similares a estes:

• · Análise de Requisitos
• · Desenho
• · Implementação
• · Teste
• · Instalação
• · Manutenção

A razão pela qual é denominado o método de Waterfall (cascata) é por que cada etapa decorre a partir da prévia quando esta se conclui, descendo como uma cascata. Como uma casta flui para baixo e nunca para cima. Este método é muitas vezes considerado como «mais seguro».

O método funciona bem em ambientes comerciais em que os contratos são assinados e o dinheiro é pago. Contudo. Quando se trabalha para clientes internos, é mais difícil fazer má cara a mudanças de última hora quando são as pessoas da organização que as pedem e muitas vezes com o apoio da gestão de topo.

Prós	Contras
Documentação detalhada	Início lento.
Requisitos acordados e assinados.	Requisitos fixos difíceis de mudar.
Pode ser desenvolvido com programadores com conjunto de competências mais baixo.	Não há visibilidade do software para o cliente até que o desenvolvimento esteja concluído.
Número reduzido de defeitos através de um planeamento do desenho.	Falta de flexibilidade tornando difícil mudar de direcção.
Pontos de início e de fim definidos para cada fase, permitindo que o progresso possa ser facilmente medido	Os Clientes não estão inicialmente conscientes dos requisitos.

Método Agile

O método Agile refere-se a uma abordagem iterativa a projectos, em que os requisitos e soluções evoluem através da colaboração entre clientes e equipas de desenvolvimento. O termo está ligado a 2001 quando foi lançado o «Agile Manifesto».

Se o gestor do projecto está receoso de cometer erros frente ao cliente este não é o melhor método a adoptar. O método Agile significa que criamos resultados o mais cedo possível e vamos refinando-os através diversas iterações com o cliente. Contudo, verifica-se que alguns stakeholders encaram negativamente esta abordagem.

Assim, será que o método Agile conduz a uma mais rápida entrega de resultados? Só porque conseguimos começar a programar mais cedo não significa necessariamente que iremos terminar mais cedo. Mas, garante que o resultado final vai de encontro às expectativas e necessidades do cliente, por que , principalmente, ele consegue oferecer válidos inputs durante toda a fase desenvolvimento.

Prós	Contras
Início rápido, releases incrementais e revisões regulares e feedback do cliente.	Pode ser mal interpretado como não planeado ou indisciplinado.
Evolução dos requisitos ao longo do tempo.	Exige uma equipa de alta qualidade que possa enfrentar o cliente.
Capacidade de resposta rápida à mudança.	Necessita de um envolvimento de alto nível por parte do cliente.
Menor trabalho repetido alcançado através de teste continue envolvimento do cliente.	Falta de planos detalhados de longo prazo.
Comunicação em tempo real entre o desenvolvimento e o cliente.	Produz documentação de baixo nível.

Conclusão

Então qual é o melhor método, Waterfall ou Agile?

Nenhum…

O método que usamos depende de vários factores, tais como:

Tipo de trabalho: há um resultado claramente definido? O desenvolvimento de sites da web é criativo e adere com facilidade ao método Agile. Já o desenvolvimento de sistemas de transacções, onde existe um resultado claramente definido adapta-se melhor ao método Waterfall.

Tipo de cliente: será que o cliente está disposto a trabalhar de forma iterativa, terão tempo suficiente para rever e comentar as iterações regulares?

Ponto de vista do gestor: Será que ele favorece um método relativamente ao outro. Até que ponto é ele adaptável?

Apreciação das TI na organização: as TI são vistas como um parceiro valioso ou um mal necessário? Se o ponto de vista é o último, então utilize o método de Waterfall.

Cliente externo ou interno: o seu cliente é externo ou interno? O método Waterfall funciona bem com clientes externos para os quais é normal existir um contrato assinado, pelo contrário com os clientes internos podem forçar mudanças com base no suporte da gestão de topo.

O gestor de projecto deve seleccionar o método que melhor satisfaça as necessidades dos utilizadores. O problema surge quando existem diferenças de opinião. Neste caso, escolha o método que irá realizar o melhor resultado e faça a gestão dos desacordos.

No fim ambos os métodos podem realizar o projecto. O segredo está na gestão das expectativas do cliente e na realização de um produto de qualidade. A realidade é que quando se chega ao fim da viagem, já ninguém se importa como é que lá se chegou.

LQ

Conhecer os custos de um projecto não é suficiente!

Para se poder compreender o verdadeiro valor de um projecto e decidir se o levamos a cabo ou não (ou mesmo até, em primeiro lugar, iniciá-lo) não é muito útil considerar unicamente os custos. Se os benefícios excedem os custos então não há razão porque os custos não podem aumentar. O que é importante é que os benefícios continuem a exceder os custos.

Quando a organização pretende verificar se estes componentes se mantêm em desequilíbrio é porque pretende validar a realização.

Quando analisamos os custos torna-se vital que também verifiquemos os benefícios. Nós temos coisas chamadas centros de custo onde todos os custos relevantes são acumulados e mantidos e inevitavelmente debruçamo-nos sobre eles, analisamo-los e revemo-los, etc. E então o que fazemos com os benefícios? Quando foi a última vez que ouvimos falar de um centro de benefícios?

O que precisa então ser conhecido acerca destes benefícios que podem vir a ocorrer num futuro incerto? A próxima vez que estiver num projecto pense acerca do que pode ser necessário registar destes benefícios, para garantir que são compreendidos de forma adequada a poderem ser reconciliados com os custos. Sugeria o seguinte:

• Descrição do Benefício – uma narrativa que nos ajude a compreender o âmbito daquilo que esperamos obter.
• Quando é expectável ocorrer o benefício e qual o período durante o qual se realizará – os benefícios são raramente óbvios de forma imediata. Taxa Interna de Retorno, Valor Líquido Presente, Payback e outros indicadores financeiros trabalham tão bem com benefícios como com custos.
• Medir a realização do benefício e como será obtida – como iremos medir o verdadeiro valor e particularmente como é que o poderemos medir. Não se esqueça de fazer uma avaliação do «estado actual» já que todas as melhorias devem ser medidas em relação com alguma coisa.
• Que custos estão directamente associados com os benefícios em questão.
• Qual o projecto que irá realizar os outputs que permitirão obter os benefícios.
• Que riscos podem estar associados com o caminho de obtenção do benefício.
• Quem irá ser responsável e proprietário da realização dos benefícios.

Se registamos os benefícios desde o início estaremos em boa posição para validarmos as razões para o projecto e aptos a demonstrar a sua viabilidade.