segunda-feira, 24 de novembro de 2014
domingo, 28 de setembro de 2014
quinta-feira, 25 de setembro de 2014
.jpg)
segunda-feira, 8 de setembro de 2014
quinta-feira, 28 de agosto de 2014
terça-feira, 26 de agosto de 2014
terça-feira, 12 de agosto de 2014
Pesquisa: Utilização dos artefatos de gerenciamento de projeto
Este blog apoia as ações acadêmicas dos praticantes para pesquisas científicas e publicações de artigos que possam agregar valor para a nossa comunidade.
Esta pesquisa está vinculada ao estudo de Felipe de Souza Mendes e Silva como exigência para obtenção do grau de Mestre pelo Programa de Pós-Graduação em Gestão Empresarial pela FGV-RJ com o objetivo de identificar os principais artefatos utilizados para o gerenciamento de projetos, usando métodos clássicos ou ágeis.
A pesquisa deve ser respondida até 30/Setembro/2014.
Link para pesquisa: http://pesquisa.fgv.br/index.php?sid=79579&lang=pt-BR
Demais dúvidas e/ou esclarecimentos a respeito da pesquisa em: felipe.msouza@fgv.br
quinta-feira, 19 de junho de 2014
CNJ deve monitorar a gestão de projetos para garantir bons resultados
Gláucio Dettmar/Agência CNJ
Especialistas em gerenciamento de
projetos de vários órgãos do judiciário reuniram-se no Conselho Nacional de
Justiça (CNJ), no último dia 13, para discutir o modelo que será utilizado para
monitorar projetos de âmbito nacional. Na próxima etapa do trabalho, esses
especialistas encaminharão ao CNJ, até o final de julho, propostas que serão
compiladas pelo conselho.
A ideia é que boas práticas sejam
difundidas em todo o Judiciário e, sempre que possível, seus resultados sejam monitorados.
Com a criação do modelo, a partir de 2015, o Judiciário selecionará programas e
projetos, aplicáveis a todos os órgãos ou a determinados segmentos de Justiça,
e gerenciará as iniciativas para garantir o cumprimento, o alcance e o
resultado das chamadas Metas Nacionais.
“Essas iniciativas é que vão dar
suporte à execução da Estratégia”, esclareceu o Diretor de Gestão Estratégica
do CNJ, Ivan Bonifácio. “Para uma boa gestão da Justiça, não é suficiente
apenas a definição de metas para todo o Judiciário: é preciso também priorizar
ações que viabilizem a concretização dos resultados esperados”, comentou.
Atualmente, a gestão da Estratégia
Nacional do Judiciário prioriza a definição, o monitoramento e a divulgação das
Metas Nacionais. Para cada meta que o CNJ apresenta ao Poder Judiciário, no
mínimo uma ação é responsável por aquele resultado. Para contribuir na execução
da Meta 1, por exemplo, e melhorar os indicadores de produtividade, os
tribunais estão utilizando o Processo Judicial Eletrônico (PJe).
As seis Metas Nacionais são: 1º) Julgar
mais processos que os distribuídos neste ano; 2º) Julgar os processos mais
antigos; 3º) Fazer a distribuição igualitária entre força de trabalho e
demandas de processos, garantindo estrutura mínima; 4º) Julgar todos os casos
de improbidade administrativa e crimes contra administração pública,
distribuídos até dezembro de 2012; 5º) Reduzir o congestionamento em relação à
taxa média de 2013 e 2012, na fase de cumprimento de sentença de execução
(específica das Justiças Federal e do Trabalho); e 6º) Julgar as chamadas ações
coletivas distribuídas no primeiro e no segundo grau.
Após a seleção das boas práticas, as iniciativas escolhidas serão incluídas no Banco de Boas Práticas (BPIJus) e todos os tribunais deverão seguir o modelo de gestão validado pela Rede de Governança Colaborativa do Poder Judiciário.
Após a seleção das boas práticas, as iniciativas escolhidas serão incluídas no Banco de Boas Práticas (BPIJus) e todos os tribunais deverão seguir o modelo de gestão validado pela Rede de Governança Colaborativa do Poder Judiciário.
A proposta de modelo de monitoramento
foi discutida em reunião entre gestores de escritórios de projetos de alguns
tribunais e conselhos, o juiz auxiliar da presidência Clenio Jair Schulze e
equipe de servidores do Departamento de Gestão Estratégica (DGE) do CNJ. Na
ocasião, também foi apresentado estudo preliminar feito pelo DGE sobre a
maturidade em gerenciamento de projetos nos órgãos do Judiciário.
Responderam, ao CNJ, 55 dos 92 tribunais e conselhos; os dados revelaram que 89% dos tribunais já estruturaram seus escritórios de projetos, 71% já adotam metodologia e 46% aplicam essa metodologia nos projetos estratégicos de seus órgãos.
Responderam, ao CNJ, 55 dos 92 tribunais e conselhos; os dados revelaram que 89% dos tribunais já estruturaram seus escritórios de projetos, 71% já adotam metodologia e 46% aplicam essa metodologia nos projetos estratégicos de seus órgãos.
O diagnóstico mostrou também que mais
de 80% dos tribunais monitoram seus projetos, mas que apenas 38% tratam os
riscos relacionados à implementação dessas iniciativas.
Regina Bandeira
Agência CNBJ de Notícias
Agência CNBJ de Notícias
quarta-feira, 23 de abril de 2014
Relatórios de gerenciamento de projetos
Fonte : PMI
Autora: Jennifer Whitt
1. Relatório de Consumo de Horas
O relatório de horas reflete todos os tempo aplicado por seus recursos em seus projetos. Ele permite que você controle o tempo real contra o tempo que foi alocado e aprovado no seu orçamento. É útil não só para o gerente, mas ele também para os companheiros de equipe ou qualquer fornecedor que reporte o tempo em seus projetos, já que eles são responsáveis pelo que estão relatando. Eu recomendo que as pessoas reportem o tempo semanalmente, mas é ainda mais válido se as pessoas controlarem seu tempo no projeto em tempo real.
2. Relatório de Despesas
As despesas podem matar projetos se não são bem controladas. Um gerente de projeto pode pensar que o trabalho está indo bem até que todos reportem as despesas no final, e a essa altura ele rapidamente se transforma em um projeto fracassado, porque as pessoas não informaram suas despesas em tempo real. Despesas incluem:
Tempo de empreiteiros e fornecedores;
Despesas de viagem, como passagem aérea, táxis, hotéis, refeições, etc;
Refeições e entretenimento (especialmente em atividades comerciais);
Suprimentos que são consumidos e alocados a seu projeto;
Equipamentos, pois quando algumas equipes de projeto são alocadas em determinadas áreas do projeto, eles podem ter que encomendar equipamentos como impressoras, laptops adicionais, etc, que têm de ser contabilizados;
Aluguel e instalações, já que algumas equipes de projeto podem alugar ou arrendar espaço de escritório que tem de ser contabilizado em seus projetos;
Controle as despesas em tempo real, de modo que elas não atinjam o seu projeto no final de surpresa e causem o fracasso. Aqueles que podem querer olhar para relatórios de despesas incluem você como o Gerente de Projetos, aqueles que aprovam relatórios de despesas, o departamento financeiro da empresa e qualquer um que informa as despesas para o seu projeto.
3. Relatório de Carga de Trabalho dos Recursos
Assim como o relatório de horas permite que você acompanhe o real versus o estimado para que você possa olhar para as variações, o relatório de carga de trabalho dos recursos também é muito importante para o gerente de projeto. Os membros da equipe também podem se beneficiar dos insights deste relatório, porque eles são os que normalmente fazem a estimativa do trabalho necessário, e desejam controlar o tempo real utilizado. Eles precisam ser capazes de olhar para a sua própria carga de trabalho e chamar a atenção para eles onde podem estar com excesso de alocação de horas.
O relatório de carga de trabalho dos recursos olha para aquilo que você tem no orçamento. Se você tem duas pessoas com as mesmas habilidades, pode ser possível realocar algum trabalho a outros recursos. Se negligenciado, estas são coisas que podem fazer um projeto ficar acima do orçamento ou em atraso.
4. Relatório de Portfólio
A maioria dos gerentes de projeto gerencia múltiplos projetos. Pessoalmente, eu gosto de informações de alto nível em meu relatório de portfólio, como metas e status. Se algo está vermelho, significando que um projeto está fora da caminho desejado, isso me obriga a dar uma olhada mais de perto nos detalhes do projeto.
5. Relatório de Status do Projeto
Existem vários formatos para acompanhamento de dados, mas eu sou uma pessoa muito visual que gosta de gráficos no relatório de status. Os gráficos podem ser do tipo pizza, histogramas, lineares ou infográficos. Você também pode preferir preparar os dados em um formato de planilha. Estes são alguns dos itens que eu procuro em um relatório de status do projeto:
Trabalho que está concluído ou atrasado, e quando está prevista para ser concluído;
Variações do cronograma;
Variações de custos;
Riscos (certificar que todos os riscos estão sendo atendidos);
Problemas (certificar que esses problemas estão sendo endereçados adequadamente);
Alterações (que mudanças estão chegando ou precisam ser avaliadas pelo conselho de controle de mudanças);
Eu compartilho relatórios de status com o conselho de controle de mudanças de cada projeto com o detalhamento que preferem, que pode ser uma visão de alto nível dos dados, para em seguida fornecer uma visão mais detalhada do status para os membros da minha equipe. Os softwares de hoje permitem que você personalize como os dados são apresentados.
Analisar os dados por meio de relatórios de gerenciamento de projeto lhe dá importantes insights sobre o seu projeto, e pode mostrar o que está indo bem e o que não está. Manter o controle de detalhes do projeto pode significar a diferença entre um projeto fracassado e um projeto bem sucedido.
Autora: Jennifer Whitt
Artigo publicado originalmente em http://stakeholdernews.com.br/artigo/relatorios-gerenciamento-de-projetos/#sthash.fajVKH3k.dpuf
sábado, 19 de abril de 2014
Padrão para Gerência de Portfolio (The Standard for Portfólio Management)
Um portfólio ou uma carteira é
uma coleção de componentes de programas, projetos ou operações gerenciadas como
um grupo para alcançar objetivos estratégicos (PMI). Uma carteira é composta por projetos escolhidos mediante algum critério (risco versus retorno , por exemplo) e deve ser priorizada de acordo com a estratégia da organização. Como uma carteira de investimentos , as escolhas para a carteira de projeto podem ser mais ou menos agressiva em termos de retorno. Em geral, maior risco esta relacionado a maior retorno.
Existem conceitos fundamentais para entender a gestão de portfólio :
• Os componentes da carteira podem não ser necessariamente interdependentes.
• A carteira pode ser constituída
por um conjunto de componentes do passado, presente e do futuro.
• Uma organização pode ter mais
de um portfolio , cada um abordando estratégias organizacionais e objetivos
únicos.
Sobre portfólio a figura abaixo mostra a relação com subportfólios, programas, projetos e operação.
Sobre gestão de portfólio é importante saber que :
Sobre portfólio a figura abaixo mostra a relação com subportfólios, programas, projetos e operação.
Fonte : PMI
Sobre gestão de portfólio é importante saber que :
• Gestão de portfólio inclui a
identificação , categorização , avaliação, seleção de componentes para melhor
realizar as estratégias organizacionais.
• Gestão de portfólio procurar
atender demandas conflitantes de programas e projetos para definir a alocação
de recursos (por exemplo, pessoas, financiamento) com base em prioridades e
capacidade de organização .
O que muita gente não sabe é que já existe um padrão para gestão de portfólios como acontece com o gerenciamento de projetos. O Padrão para Gerenciamento de Portfólio do PMI está na 3 ª Edição e define processos de gerenciamento de portfólio e áreas de conhecimento.
O gerenciamento de portfólio acontece no contexto da organização. O diagrama abaixo relaciona o gerenciamento de porfólio com objetivos estratégicos , atividades recorrentes e atividades projetizadas.
As entregas do padrão de gestão de portfólio são :
Fonte : PMI
As entregas do padrão de gestão de portfólio são :
- O Plano Estratégico do Portfolio: Inclui visão da carteira, alinhamento estratégico , a abordagem , o modelo de priorização , os fundos e os recursos disponíveis .
- O Portfolio Charter : Inclui escopo de alto nível , cronogramas de alto nível, critérios de sucesso e principais partes interessadas.
- O Plano de Gerenciamento de Portfolio: Envolve aspectos de governança, risco , performance, mudança, comunicação , aquisições, compliance)
- O Roadmap do Portfolio : Envolve os componentes, os marcos importantes e dependências de uma forma cronológica .
- O Portfolio: É a coleção de projetos, programas e outros trabalhos que são agrupados para facilitar o gerenciamento eficaz desse trabalho para atender aos objetivos de negócios estratégicos.
Os grupos de processos do
standard de gestão de portfólio são :
- Definição : Define como a estratégia organizacional será implementado em uma carteira ( portfólio plano estratégico , mapa rodoviário, fretamento e plano de gestão ) . 8 processos
- Alinhamento : Gerencia e otimiza o portfólio (avaliação componentes , priorização , seleção , modificação ou eliminação ) . 6 processos
- Autorização e controle : Autoriza a carteira de componentes e fornece uma supervisão contínua. 2 processos
As Áreas de Conhecimento do standard
de gestão de portfólio são :
- Gestão Estratégica : Garante o alinhamento com a estratégia organizacional. 4 processos
- Gestão de Governança: Inclui a supervisão do portfólio e apoio do corpo atividades de tomada de decisão de governança . 5 processos
- Gestão de Portfólio : Gerencia a alocação de recursos e acompanha o desempenho de carteiras e realização de valor . 3 processos
- Gerência de Comunicação : Desenvolve o plano de gerenciamento de portfólio de comunicação e gerir a carteira de informações. 2 processos
- Gestão de Riscos: Desenvolve o plano de gerenciamento de risco da carteira e gerenciar os riscos da carteira . 2 processos
Fonte :PMI
Fonte : PMI.
sexta-feira, 11 de abril de 2014
Todo mundo quer contratar gerentes de projeto !
Responsável por assegurar a entrega das
diversas obras em andamento no Brasil, o gerente de projetos é o profissional
que tem vaga em praticamente todos os mercados
publicado originalmente na Voçe S/A.
Em tempos de
crescente pressão para se fazer mais com menos, a demanda por esse profissional
está em alta no mundo todo. De acordo com o Project Management Institute (PMI),
associação que reúne e certifica profissionais do setor, serão criados 13
milhões de novos postos para gerente de projetos globalmente até 2020.
Com Copa e Olimpíada
no horizonte, reservas de petróleo no pré-sal a serem exploradas e obras de
infraestrutura a todo vapor, o Brasil ostenta uma constelação de projetos a
serem entregues.
O país tem a quinta
maior demanda por gerentes de projetos do mundo. Nos próximos sete anos, serão
necessários mais de 1,3 milhão de profissionais para dar conta do recado. “O
capital investido nesses projetos é altíssimo e qualquer falha representa um
prejuízo enorme”, diz Ricardo Triana, vice-presidente do conselho diretivo do PMI.
Diante de tanta
responsabilidade, a recompensa é alta. O salário médio de um gerente de
projetos no Brasil, segundo levantamento do PMI, é de 12 000 reais mensais. De
acordo com a consultoria de recrutamento Michael Page, os contracheques variam
de 8 000 a 18 000 reais, em média, mas é possível encontrar profissionais
ganhando até 50 000 reais.
“O que determina o
valor é a experiência da pessoa e o quanto ela pode trazer de retorno para a
empresa”, diz Lucas Toledo, gerente executivo da Michael Page. “Em um grande
projeto, como uma mina, por exemplo, uma entrega antecipada significa uma
economia de milhões.”
De olho nesses
potenciais benefícios, a Rolls-Royce, que opera
nas indústrias naval, de energia e defesa civil, entre outras, firmou uma
parceria com a Universidade de Manchester para trazer ao Brasil um programa
diferenciado de formação de gerente de projetos. A iniciativa nasceu no Reino
Unido, em 1999, de uma parceria entre a universidade e a empresa, e foi
replicada apenas em outros dois países: Estados Unidos e Singapura.
No exterior, o
programa de mestrado já capacitou mais de 400 alunos — 148 deles funcionários
da Rolls-Royce. A iniciativa de trazer o programa para o Brasil partiu da
Universidade de Manchester e foi abraçada pela Rolls-Royce, que patrocinará
integralmente o custo de 60 000 reais por aluno para matricular seus
funcionários no curso.
A primeira turma deve
iniciar o programa até meados de 2014 e as aulas serão oferecidas em parceria
com uma instituição acadêmica brasileira — a universidade inglesa está em
negociações com Fundação Getulio
Vargas, Universidade de
São Paulo e Coppead (da Universidade Federal do Rio de
Janeiro). Empresas parceiras da Rolls-Royce, como Petrobras, British Gas e
Embraer, também serão convidadas a matricular alunos no programa.
Essa não é uma iniciativa isolada. Segundo o PMI, o volume de cursos
voltados a capacitar gerentes de projetos em universidades brasileiras cresceu
80% nos últimos cinco anos. Mesmo assim, as certificações ainda são uma
importante porta de entrada para quem quiser ingressar nessa carreira. O
objetivo delas é comprovar os conhecimentos técnicos e a experiência dos
profissionais da área.
Há diferentes níveis
e modalidades, com diversas entidades certificadoras no mercado. Na teoria,
elas são mais um pré-requisito do que um diferencial. Mas, em alguns casos,
acabam impactando na remuneração — de acordo com a Michael Page, uma
certificação pode representar um aumento imediato de até 2 000 reais no salário
do profissional e ainda tem o potencial de abrir novas portas.
Outras habilidades
Mas, se a
certificação ajuda a abrir portas, o sucesso de um gerente de projetos na
carreira depende de um conjunto mais amplo de fatores. O conhecimento das
ferramentas e das técnicas de gestão de projetos é só uma parte do pacote. Além
da capacidade de aplicar esses recursos, o bom gerente de projetos precisa de
habilidades interpessoais, como capacidade de liderança, comunicação,
negociação e empatia.
“Saber lidar com
gente é fundamental, pois quem entrega o projeto não é o gerente, é a equipe”,
diz Alex Julian, de 35 anos, gerente de projetos, programas e portfólio do Citibank. Pós-graduado
em gerenciamento de projetos pela Fiap e certificado em project management
professional (PMP) pelo PMI, ele acredita que o bom gerente de projetos não é
aquele que só controla planilhas, mas quem se comunica bem com o time, entende
seus problemas e ajuda a resolvê-los.
“É fundamental
conhecer bem todos os envolvidos no projeto para entender qual o tipo de
comunicação ideal. Não adianta fazer um relatório gigante de andamento do
projeto para um diretor que vai ler no Blackberry”, diz Alex.
Durante a
implementação de um projeto de integração da plataforma de negociação da
BM&FBovespa com a bolsa de Chicago, ele criou um jornalzinho impresso para
comunicar o andamento do processo a todas as áreas envolvidas. “Isso fez com
que pessoas que estavam lá no fim da cadeia, que estavam fora das discussões
mas que seriam afetadas pelas mudanças, entendessem o que estava acontecendo e
pudessem trazer contribuições”, diz Alex.
Situações extremas
A capacidade de lidar
com a pressão é outro pré-requisito desse profissional. O brasileiro Ricardo
Vargas, de 40 anos, diretor do Grupo de Práticas de Gestão de Projetos
Sustentáveis do Escritório de Serviços de Projetos das Nações Unidas, sente
isso na pele todos os dias.
“O papel de um
gerente de projetos é sempre buscar eficiência. A diferença é que, na
iniciativa privada, o fracasso significa perder dinheiro. Aqui pode significar
vidas”, diz.
À frente de uma
equipe de 300 gerentes de projetos e de um orçamento de 1 bilhão de dólares,
ele é responsável por iniciativas que vão desde construir uma estrada no
Afeganistão até erguer uma escola na África. “A pressão é 24 horas por dia.
Ninguém liga para dizer que está tudo bem”, diz Ricardo.
A chave para o
sucesso na profissão, de acordo com Ricardo — que antes de ser convidado para
assumir o posto nas Nações Unidas liderou projetos de dezenas de bilhões de
dólares em companhias privadas como Gerdau, Bradesco e Andrade Gutierrez —, é
ter capacidade de liderança e visão do todo.
“O técnico não
precisa ter sido o jogador mais brilhante. Ele tem de entender como o jogo é
jogado e criar modelos de incentivo para que os jogadores trabalhem como um
grupo, e não como um bando desordenado”, diz Ricardo.
domingo, 16 de março de 2014
Negociação em Projetos
A negociação é
um aspecto essencial a ser considerado no gerenciamento de projetos e a falta
de habilidade em negociar é apontada como causa frequente de fracasso em projetos. Existem três tipos básicos
de negociação: negociação distributiva ,
negociação integrativa e negociação
criativa.
Negociações distributivas.
As negociações distributivas envolvem apenas uma questão, normalmente relacionada a valores. Como exemplo de sua aplicação pode-se citar a compra ou venda de um carro, em que a única questão a ser negociada é o valor do automóvel. Normalmente essa negociação é conduzida em um ambiente competitivo. Cada parte apresenta um valor de abertura e se planeja para não ultrapassar determinado valor limite. Por definição, é sempre ganha-perde.
As negociações distributivas envolvem apenas uma questão, normalmente relacionada a valores. Como exemplo de sua aplicação pode-se citar a compra ou venda de um carro, em que a única questão a ser negociada é o valor do automóvel. Normalmente essa negociação é conduzida em um ambiente competitivo. Cada parte apresenta um valor de abertura e se planeja para não ultrapassar determinado valor limite. Por definição, é sempre ganha-perde.
Negociações integrativas.
As negociações integrativas envolvem diversas questões. Como exemplo de aplicação pode-se citar a mesma compra ou venda de um carro, mas ao invés de negociar apenas o valor do automóvel, negocia-se também o prazo de pagamento, a inclusão de certos acessórios, a data de entrega, etc. Essa negociação pode ser conduzida tanto em um ambiente competitivo como colaborativo. No ambiente competitivo torna-se mais difícil para as partes alcançarem um bom resultado, devido à omissão ou distorção de informações ou a manobras para adquirir poder de influência. No ambiente colaborativo, em que ambas as partes são mais transparentes na divulgação de seus interesses, limites e prioridades, são criadas as condições ideais para uma solução ganha-ganha.
As negociações integrativas envolvem diversas questões. Como exemplo de aplicação pode-se citar a mesma compra ou venda de um carro, mas ao invés de negociar apenas o valor do automóvel, negocia-se também o prazo de pagamento, a inclusão de certos acessórios, a data de entrega, etc. Essa negociação pode ser conduzida tanto em um ambiente competitivo como colaborativo. No ambiente competitivo torna-se mais difícil para as partes alcançarem um bom resultado, devido à omissão ou distorção de informações ou a manobras para adquirir poder de influência. No ambiente colaborativo, em que ambas as partes são mais transparentes na divulgação de seus interesses, limites e prioridades, são criadas as condições ideais para uma solução ganha-ganha.
Negociações criativas.
Na negociação criativa , cada parte revela seus interesses, a partir dos quais busca soluções que sejam capazes de atender a maior quantidade possível de interesses envolvidos. Essa negociação é ideal para encontrar soluções conciliadoras para problemas complexos. Deve ser conduzida em um ambiente colaborativo e emprega largamente os princípios de negociação apresentados por William Ury: foque nas pessoas, não nos problemas; diferencie posições de interesses, etc.
Na negociação criativa , cada parte revela seus interesses, a partir dos quais busca soluções que sejam capazes de atender a maior quantidade possível de interesses envolvidos. Essa negociação é ideal para encontrar soluções conciliadoras para problemas complexos. Deve ser conduzida em um ambiente colaborativo e emprega largamente os princípios de negociação apresentados por William Ury: foque nas pessoas, não nos problemas; diferencie posições de interesses, etc.
Negociações em projetos.
Em negociações complexas, como as conduzidas em projetos ou contratos de grande grande porte, é comum que o negociador necessite utilizar as técnicas necessárias para conduzir os três tipos de negociação, simultaneamente.
Em negociações complexas, como as conduzidas em projetos ou contratos de grande grande porte, é comum que o negociador necessite utilizar as técnicas necessárias para conduzir os três tipos de negociação, simultaneamente.
Fonte: wikipedia.
sábado, 19 de outubro de 2013
terça-feira, 15 de outubro de 2013
terça-feira, 20 de agosto de 2013
Melhorar a entrega de projetos de TI é prioridade para CIOs, revela pesquisa
Aumentar o rendimento dos projetos de
TI para os negócios é uma das 5 iniciativas mais importantes nos próximos 12
meses, segundo CIOs ouvidos pela Forrester a pedido da Blue Coat
Cristina De Luca (@DeLuCa)
No último trimestre de 2012, pesquisa da Forrester, patrocinada pela
Blue Coat, pediu a executivos de TI para que identificassem as iniciativas mais
importantes para os próximos 12 meses. Dos 43 diretores e vice-presidentes
ouvidos, 72% relataram "melhorar o desempenho na entrega de projetos de
TI" como uma prioridade alta, outros 67% apontaram "desenvolver novas
habilidades para melhorar as tecnologias emergentes de apoio e inovação
empresarial".
Apesar de importante, a segurança é vista como um obstáculo ao progresso
e à inovação. Razão pela qual os CIOs já se preocupem em reduzir riscos com
políticas e medidas apropriadas, que não comprometam a funcionalidade,
usabilidade e o ritmo da implementação já que, definitivamente, a segurança não
pode ser obstáculo, mas ferramenta para viabilizar os negócios, garantindo o
crescimento da empresa.
Líderes de negócios e de TI muitas vezes consideram a segurança como um
obstáculo à consumerização. Dispositivos móveis e soluções de cloud computing ajudam
os funcionários a trabalhar de qualquer lugar, a qualquer momento, enquanto as
aplicações, serviços e ferramentas de colaboração nesses dispositivos ajudam os
empregados a se conectarem uns com os outros, para resolver problemas, e
diretamente com os clientes, além de criar soluções inovadoras.
A consumerização mostra como o equilíbrio de poder está mudando dos
departamentos de TI para os donos das empresas e os usuários finais. Na
verdade, de acordo com o estudo, 60% dos executivos de TI concordam que esta
mudança já está ocorrendo e alterando o papel do CIO de um provedor de
aplicações e infraestrutura básica e industrial para um provedor de serviços de
TI de alto valor.
Não surpreendentemente, 80% dos executivos de TI entrevistados concordam
que essa mudança de poder criou obstáculos que impedem a implementação de
medidas segurança adequadas.
Significa que, se a área de TI já não consegue mais bloquear ou inibir a
adoção corporativa de qualquer novo serviço ou tecnologia de forma
significativa, ela vai precisar adaptar suas abordagens e metodologias. Adotar
uma abordagem baseada no risco, capaz de alcançar o equilíbrio entre a
segurança e as necessidades do negócio e a experiência do usuário, e
metodologias capazes de enfrentar essas tendências, suave e silenciosamente.
"O que percebemos é que nós, fornecedores de soluções de segurança,
precisamos ajudar os CIOs a pararem de dizer não e adotarem a segurança como
uma base para a oferta de serviços de TI que permitam às empresas ampliar a
produtividade dos funcionários e a inovação de processos e dos negócios.
Funcionários com autonomia para comunicar, colaborar e executar, geram melhores
resultados para os negócios", afirma Ray Jimenez, vice-presidente de
operações da Blue Coat para a América Latina e Caribe.
Para atender a essas demandas, a Blue Coat está incluindo ao seu
portfólio soluções que tornem menos complexas as tarefas de identificar,
priorizar e solucionar ameaças de modo rápido (abaixo da média de 80 dias para
descobrir violações maliciosas e mais 123 dias para resolver o problema,
segundo pesquisa recente do do Instituto Ponemon), para que as empresas se
protejam contra ataques direcionados avançados e os solucionem rapidamente.
Entre essas soluções estão as recém-lançadas ThreatBLADES, que trabalham
integradas à plataforma de análise de segurança da Solera Networks, adquirida
recentemente pela Blue Coat, com chegada ao mercado brasileiro prevista para o
último trimestre de 2013. Em um primeiro momento, as ferramentas analisarão
todo o tráfego Web e, em uma futura versão, também os apps disponíveis em
dispositivos móveis.
quarta-feira, 7 de agosto de 2013
domingo, 4 de agosto de 2013
47 Processos do guia PMBOK Quinta Edição
por Mário Trentin, publicado originalmente no blog Mundo PM
Primeiramente, cumpre ressaltar que não houve mudança nos Grupos de Processos, que continuam sendo:
- Iniciação
- Planejamento
- Execução
- Monitoramento e Controle
- Encerramento
Figura 1 – Grupos de Processos
Dentre as novidades, em relação aos processos, houve a criação da nova área do conhecimento chamada Stakeholders ou Partes Interessadas. Na versão anterior, Guia PMBOK 4a edição, existiam 42 processos. Nesta nova edição, temos 47 processos. Foram adicionados os seguintes processos:
- Planejar Gerenciamento do Escopo
- Planejar Gerenciamento do Tempo
- Planejar Gerenciamento do Custo
- Planejar Gerenciamento dos Stakeholders
- Controlar Stakeholders
Vale ressaltar que o Guia PMBOK 5a edição já está disponível em inglês, mas ainda não existe a tradução oficial para português. Logo, os nomes dos processos foram traduzidos por mim, tradução livre e não oficial.
Além dos cinco novos processos, alguns processos foram renomeados: 5.5; 8.3; 10.2; 10.3 e 12.3. Os processos 13.1 e 13.3 pertenciam à área do conhecimento Comunicação e foram transferidos para a nova área Stakeholders. A seguir, temos os processos do Guia PMBOK 5aedição.
Figura 2 – Processos do Guia PMBOK 5a edição
Figura 3 – Processos do Guia PMBOK 5a ediçãosábado, 3 de agosto de 2013
quinta-feira, 18 de julho de 2013
domingo, 14 de julho de 2013
sexta-feira, 24 de maio de 2013
11 sinais de que seu projeto de TI está condenado
Roger A. Grimes, INFOWORLD/EUA
O mundo da TI está familiarizado com projetos que fracassam. E qualquer um que tenha participado de um esforço de TI mal-sucedido possivelmente sentiu os sinais do fracasso antes da data de lançamento. Esse sexto sentido é inestimável em um campo concorrido como o da TI – mas apenas se for usado, e de maneira ágil e profissional.
Esteja você buscando evitar estar fadado a um fracasso ou recolocar um projeto fracassado de volta ao prumo, você deve ser capaz de reconhecer os sinais de fracasso iminente muito antes do projeto sair do prumo, desandar completamente. Isso pode salvar sua carreira.
Nós enumeramos 11 sinais de alerta que devem ser observados para avaliar a saúde de um projeto de TI. Seja proativo sempre que você encontrar um deles – ou simplesmente se afaste. Sua carreira depende disso.
Nº 1: O projeto foi lançado sem o apoio da diretoria
Quer uma receita infalível para a falha de um projeto de TI? Comece a trabalhar antes de receber o sinal verde dos níveis superiores.
Isso nunca acontece? Pense bem... Uma personalidade forte dentro da empresa cria uma ideia ou solução absolutamente “tremenda” e começa a planejar reuniões e a alocar recursos sem esperar para ver se a gestão sênior concorda. Muitos desses projetos prosseguem, até o ponto onde algum dinheiro de verdade deve ser gasto, e então eles entram em um colapso total. Muitas vezes, todos no projeto, exceto seu criador, nem mesmo sabem que o projeto não foi aprovado, e nem que o orçamento não foi alocado.
Para evitar prender-se a tal projeto, sempre pergunte quem dentro da área de gestão sênior é um patrocinador e como será feita a alocação de orçamento. Não aceite respostas como a de que o orçamento ainda não foi alocado, pois as pessoas não sabem o quanto irá custar até o projeto ter sido iniciado.
Caso você seja um consultor sendo atraído para o projeto, certifique-se de que um orçamento significativo foi alocado antes de participar da segunda reunião. Você não precisa saber o valor do orçamento final, mas precisa saber que a gestão sênior é séria com relação a seu suporte e que possui alguma ideia do custo eventual. Eu já participei de grandes projetos que obviamente custariam milhões de dólares para serem resolvidos, mas a gestão estava pensando na faixa de alguns milhares de dólares. Não fique preso em tal projeto.
Nº 2: Não existe um plano detalhado do projeto
Um software de planejamento de projeto pode ser complexo e frustrante de usar. A única coisa que eu odeio mais do que arquitetar um plano de projeto detalhado é estar envolvido em um projeto que não possui um. Os planos formais de projeto forçam o administrador e todos os envolvidos a considerarem todas as fases e etapas necessárias, e a ordem na qual prosseguir. Para parafrasear uma frase frequentemente citada, “falhar ao planejar é planejar para falhar”.
Qualquer projeto com um cronograma maior do que de duas semanas deve possuir um plano de projeto sólido e planejado. Caso você seja apresentado um projeto que não possua tais características, desenvolva-as. Além de forçar todos a considerar todas as tarefas e táticas, fazê-lo os forçará a criar agendas realistas. Um plano de projeto detalhado é muito melhor do que sua “melhor suposição” ou intuição.
Nº 3: Reuniões foram agendadas sem preocupação com a disponibilidade de membros da equipe
Quando um projeto ou líder de equipe arbitrariamente agenda reuniões em conflito com outras reuniões importantes e já marcadas, você sabe que seu projeto está condenado. Fazer isso garante que membros vitais da equipe não estarão presentes, minando o propósito e eficiência de sua reunião.
A solução é simples: gaste um pouco de tempo antes de agendar reuniões de projeto para ter noção das agendas atuais dos membros importantes.
Mais importante ainda, encontre o máximo de disponibilidade comum e útil, e escolha uma oportunidade. Não vá até o extremo de permitir que os participantes votem entre múltiplas oportunidades – isto pode levar a uma diferença com aqueles que tiveram suas propostas de oportunidade negadas. Em vez disso, seja competente e escolha uma oportunidade com a qual você sabe que todos podem arcar. Você pode ajustá-la depois, caso necessário. Além disso, certifique-se de publicar os horários de reunião de sua equipe para que os outros não agendem nada sobre ela acidentalmente.
Além disso, uma dica para o sábio: agende reuniões antes do almoço, se possível. As pessoas são geralmente mais produtivas e existe uma possibilidade maior delas aparecerem mais cedo. Reuniões após o almoço, muitas vezes, vão de encontro com a lentidão de barrigas cheias e competem com as prioridades e dramas agregados durante a primeira parte do dia. As reuniões que ocorrem logo após o almoço, ou ao final do dia de trabalho, podem ser as menos frequentadas e as menos produtivas.
Nº4: Os usuários tiveram pouco (ou nenhum) envolvimento precoce
Qualquer um participando de uma aula mesmo que básica de TI na faculdade é ensinado a envolver os usuários precocemente ao lançar qualquer projeto ou processo de tomada de decisão. É por isso que é tão surpreendente ver projetos grandes e complexos quase que completamente concluídos antes que os usuários sejam trazidos para fornecerem seu conselho. Já vi muitos projetos grandes e em evolução saírem completamente do trilho depois dos usuários contarem aos lideres que um processo em particular, que não tem funcionado, também não funcionará bem depois de alterado pelo projeto.
Certifique-se de que usuários reais, ou seus defensores, sejam convidados para o projeto a partir do inicio. É preciso tê-los logo no primeiro dia. Quanto mais envolvimento você tiver por parte dos usuários, maior será sua chance de sucesso. Caso seu projeto cubra vários departamentos, certifique-se de ter um usuário representante de cada departamento. Além disso, certifique-se de que os usuários que foram convidados para participar estejam abertos aos objetivos do projeto e sintam que eles podem expressar suas verdadeiras opiniões.
Envolver usuários precocemente normalmente resulta em uma aceitação mais rápida e melhor caso problemas apareçam ou caso mudanças impopulares de processo sejam necessárias.
Nº 5: O projeto usa as especificações mínimas de hardware
Nada acaba com o sucesso de um projeto como comprar o hardware mínimo.
Os fornecedores são notórios por tentar manter o custo de um projeto baixo ao vender um hardware inferior ao necessário para os melhores resultados. Os fornecedores muitas vezes oferecem uma especificação “mínima” e o hardware recomendado para compra. Lideres inteligentes de projeto irão além até mesmo das especificações recomendadas de hardware, caso algo ocorra, pelo menos os fornecedores e seus clientes não estarão apontando seus dedos para as decisões de compra de hardware orientadas a baixo custo. Além disso, certifique-se de que todo o hardware e software comprados sejam compatíveis e testados uns com os outros. Você não quer que nenhum lado aponte culpados precocemente caso algo dê errado.
Às vezes o segredo está nos detalhes quando o assunto é comprar tecnologia. Por exemplo, caso um fornecedor diga que possui muita experiência com a execução do MySQL no Linux, tome cuidado em exigir que o MySQL funcione no Windows. O fornecedor pode dizer que pode fazê-lo, mas que pode não ter muita experiência com isso. Caso você desvie do que o fornecedor recomenda, certifique-se de obter a aceitação do fornecedor por escrito. Além disso, nunca é demais verificar com os clientes anteriores que compartilharam uma configuração semelhante a fim de saber o lado bom e o ruim de como as coisas ocorreram caso eles tenham se desviado, ainda que pouco, das especificações recomendadas.
Nº 6: Os testes estão em segundo plano
Os testes são essenciais para o sucesso de um projeto. Seja ele um teste de unidade (que testa uma faceta do sistema) ou testes integrados (que testa todos os componentes, incluindo sistemas de interface existentes). Os testes devem ser feitos pelos funcionários atuais junto com um plano de testes. O plano de testes deve incluir todos os depoimentos, passo a passo, que os testadores devem fazer. E você deve detalhar, antecipadamente, como deve ser a aparência dos resultados.
Os dados de teste e processos devem avaliar todos os cenários, incluindo os bons e os ruins. Às vezes, os resultados de dados ruins conhecidos são mais interessantes do que aqueles de um resultado desejado. Os testes devem incluir testes de carregamento para ver como o sistema e a rede responde a utilização pesada. Os testadores devem compreender os resultados esperados, e deve ser esperado que eles reportem todos os desvios.
Nº7: Não existe nenhum plano de recuperação no caso de uma falha
Apesar de nossos melhores esforços, os planos nem sempre ocorrem como esperado. Todo líder de projeto precisa saber qual será a aparência do resultado final – e quando será a hora de admitir a falha e começar novamente. Todo projeto deve ter um plano secundário de lançamento caso o fracasso se torne a única opção.
Muitos eventos de lançamento são orientados pela crença de que “nada pode dar errado”. Os lideres desses projetos muitas vezes falham em garantir que boas cópias de segurança sejam feitas e verificadas. Eles não desenvolvem protocolos para definir o sucesso, e nem esboçam antecipadamente qual seria a aparência de uma falha. Eles não preparam a equipe para o que fazer diante de um erro no lançamento. Muitos projetos completamente novos alcançam um obstáculo fatal apenas para descobrir que não podem voltar atrás, graças a um planejamento pobre.
Com algumas exceções, os projetos devem ter planos para falhas, e, quando o fracasso for grande demais, devem permitir o retorno para o sistema anterior. Claro, falhar é vergonhoso e ninguém quer ter planos para tal acontecimento. Mas não ser capaz de recuperar-se durante uma falha de serviço acaba com uma carreira.
Tornar a diretoria ciente de que você possuía um plano secundário e que seguiu ele até sua meta quando o fracasso ocorreu é uma forma de ganhar elogios. Deixar que um evento de inatividade perdure por muito tempo à medida que você explica para a administração que não existe uma forma de voltar e que o caminho à frente não tem uma aparência muito boa é uma conversa completamente diferente. Planeje obter sucesso, mas também possua um plano para o caso de um fracasso.
Nº 8: As recomendações dos especialistas foram rejeitadas sem que os resultados fossem testados
Existem pessoas que pedem por conselhos de especialistas e não dão ouvidos a eles, e então escolhem um caminho diferente – sempre. E depois reclamam quando algo não funciona corretamente.
Não seja essa pessoa. Não deixe que essa pessoa tome grandes decisões em sua equipe. Está tudo bem pedir por conselhos de especialistas e depois fazer algo diferente. Isso faz parte da natureza humana, e é muitas vezes o sinal de um bom líder. Apenas não o faça compulsivamente. Mais importante ainda, se você for contra as recomendações e o resultado não funcionar, não culpe o consultor.
Desviar das recomendações do fornecedor ou consultor significa testar os resultados de sua mudança antes de lançar o projeto. Até mesmo caso o fornecedor ou consultor concorde com seu desvio da recomendação deles, certifique-se de que a mudança seja testada. Muitos projetos falharam depois dos lideres de projeto “realizarem algumas pequenas mudanças” que deixaram os fornecedores e consultores profundamente contrariados. Você ficaria surpreso com quantos especialistas permanecem em silêncio em frente de clientes que parecem saber mais do que os experientes consultores. Todo mundo quer ser amigo. Todo mundo espera que funcione.
Não tenha esperanças. Teste. E dê ouvidos a seus especialistas na maioria das vezes.
Nº 9: A data de lançamento é em um final de semana ou feriado
Muitos lideres de projeto planejam eventos de lançamento para finais de semana ou feriados, devido as menores chances de interrupção de serviço para funcionários ou clientes. Enquanto louváveis, essas oportunidades também tendem a ser os momentos em que o suporte tecnológico é mais difícil de ser contatado. Você pode ter seu fornecedor primário no local, mas o suporte tecnológico terceiro pode estar fechado ou ocupado (e pode não estar retornando ligações em tempo hábil), e o mesmo pode ocorrer com sua equipe. Conversar com o especialista em base de dados pelo telefone enquanto ele está de férias com sua família nunca é a melhor opção.
Nº 10: As expectativas não foram definidas
Quando um novo sistema está substituindo um sistema antigo, é útil para todos compreender as novas expectativas. Como o novo sistema irá se comportar? O que mudou nas transações e nos tempos de transação? Para quem os usuários finais devem ligar caso encontrem problemas? Quando tempo a equipe de solução de problemas estará presente durante o lançamento? Um novo sistema sempre irá frustrar as pessoas, mas, caso você defina expectativas realistas e dê para as pessoas opções de suporte acelerado, os problemas tendem a sumir de modo mais rápido e você termina com clientes mais satisfeitos em pouco tempo.
Nº 11: Economia na formação
Não sei dizer quantos lideres de projeto irão descontar do orçamento de treinamento quando tiverem de encarar custos extras. Ou quantos líderes presunçosos alegam que o sistema é tão simples que os usuários não precisam de treinamento. Caso você escute, “treinaremos parte da equipe com metade das aulas e assim eles poderão treinar os outros”, ou “nossos usuários são muito bons em aprender, eles podem compreender este novo sistema em apenas alguns dias”, você saberá que está a caminho do fracasso. Não são apenas os usuários que precisam de treinamento, mas os lideres de projeto, os solucionadores de problemas e a equipe de funcionários do suporte. Esteja preparado para atrasar o projeto caso o treinamento apropriado não seja dado.
Esteja você buscando evitar estar fadado a um fracasso ou recolocar um projeto fracassado de volta ao prumo, você deve ser capaz de reconhecer os sinais de fracasso iminente muito antes do projeto sair do prumo, desandar completamente. Isso pode salvar sua carreira.
Nós enumeramos 11 sinais de alerta que devem ser observados para avaliar a saúde de um projeto de TI. Seja proativo sempre que você encontrar um deles – ou simplesmente se afaste. Sua carreira depende disso.
Nº 1: O projeto foi lançado sem o apoio da diretoria
Quer uma receita infalível para a falha de um projeto de TI? Comece a trabalhar antes de receber o sinal verde dos níveis superiores.
Isso nunca acontece? Pense bem... Uma personalidade forte dentro da empresa cria uma ideia ou solução absolutamente “tremenda” e começa a planejar reuniões e a alocar recursos sem esperar para ver se a gestão sênior concorda. Muitos desses projetos prosseguem, até o ponto onde algum dinheiro de verdade deve ser gasto, e então eles entram em um colapso total. Muitas vezes, todos no projeto, exceto seu criador, nem mesmo sabem que o projeto não foi aprovado, e nem que o orçamento não foi alocado.
Para evitar prender-se a tal projeto, sempre pergunte quem dentro da área de gestão sênior é um patrocinador e como será feita a alocação de orçamento. Não aceite respostas como a de que o orçamento ainda não foi alocado, pois as pessoas não sabem o quanto irá custar até o projeto ter sido iniciado.
Caso você seja um consultor sendo atraído para o projeto, certifique-se de que um orçamento significativo foi alocado antes de participar da segunda reunião. Você não precisa saber o valor do orçamento final, mas precisa saber que a gestão sênior é séria com relação a seu suporte e que possui alguma ideia do custo eventual. Eu já participei de grandes projetos que obviamente custariam milhões de dólares para serem resolvidos, mas a gestão estava pensando na faixa de alguns milhares de dólares. Não fique preso em tal projeto.
Nº 2: Não existe um plano detalhado do projeto
Um software de planejamento de projeto pode ser complexo e frustrante de usar. A única coisa que eu odeio mais do que arquitetar um plano de projeto detalhado é estar envolvido em um projeto que não possui um. Os planos formais de projeto forçam o administrador e todos os envolvidos a considerarem todas as fases e etapas necessárias, e a ordem na qual prosseguir. Para parafrasear uma frase frequentemente citada, “falhar ao planejar é planejar para falhar”.
Qualquer projeto com um cronograma maior do que de duas semanas deve possuir um plano de projeto sólido e planejado. Caso você seja apresentado um projeto que não possua tais características, desenvolva-as. Além de forçar todos a considerar todas as tarefas e táticas, fazê-lo os forçará a criar agendas realistas. Um plano de projeto detalhado é muito melhor do que sua “melhor suposição” ou intuição.
Nº 3: Reuniões foram agendadas sem preocupação com a disponibilidade de membros da equipe
Quando um projeto ou líder de equipe arbitrariamente agenda reuniões em conflito com outras reuniões importantes e já marcadas, você sabe que seu projeto está condenado. Fazer isso garante que membros vitais da equipe não estarão presentes, minando o propósito e eficiência de sua reunião.
A solução é simples: gaste um pouco de tempo antes de agendar reuniões de projeto para ter noção das agendas atuais dos membros importantes.
Mais importante ainda, encontre o máximo de disponibilidade comum e útil, e escolha uma oportunidade. Não vá até o extremo de permitir que os participantes votem entre múltiplas oportunidades – isto pode levar a uma diferença com aqueles que tiveram suas propostas de oportunidade negadas. Em vez disso, seja competente e escolha uma oportunidade com a qual você sabe que todos podem arcar. Você pode ajustá-la depois, caso necessário. Além disso, certifique-se de publicar os horários de reunião de sua equipe para que os outros não agendem nada sobre ela acidentalmente.
Além disso, uma dica para o sábio: agende reuniões antes do almoço, se possível. As pessoas são geralmente mais produtivas e existe uma possibilidade maior delas aparecerem mais cedo. Reuniões após o almoço, muitas vezes, vão de encontro com a lentidão de barrigas cheias e competem com as prioridades e dramas agregados durante a primeira parte do dia. As reuniões que ocorrem logo após o almoço, ou ao final do dia de trabalho, podem ser as menos frequentadas e as menos produtivas.
Nº4: Os usuários tiveram pouco (ou nenhum) envolvimento precoce
Qualquer um participando de uma aula mesmo que básica de TI na faculdade é ensinado a envolver os usuários precocemente ao lançar qualquer projeto ou processo de tomada de decisão. É por isso que é tão surpreendente ver projetos grandes e complexos quase que completamente concluídos antes que os usuários sejam trazidos para fornecerem seu conselho. Já vi muitos projetos grandes e em evolução saírem completamente do trilho depois dos usuários contarem aos lideres que um processo em particular, que não tem funcionado, também não funcionará bem depois de alterado pelo projeto.
Certifique-se de que usuários reais, ou seus defensores, sejam convidados para o projeto a partir do inicio. É preciso tê-los logo no primeiro dia. Quanto mais envolvimento você tiver por parte dos usuários, maior será sua chance de sucesso. Caso seu projeto cubra vários departamentos, certifique-se de ter um usuário representante de cada departamento. Além disso, certifique-se de que os usuários que foram convidados para participar estejam abertos aos objetivos do projeto e sintam que eles podem expressar suas verdadeiras opiniões.
Envolver usuários precocemente normalmente resulta em uma aceitação mais rápida e melhor caso problemas apareçam ou caso mudanças impopulares de processo sejam necessárias.
Nº 5: O projeto usa as especificações mínimas de hardware
Nada acaba com o sucesso de um projeto como comprar o hardware mínimo.
Os fornecedores são notórios por tentar manter o custo de um projeto baixo ao vender um hardware inferior ao necessário para os melhores resultados. Os fornecedores muitas vezes oferecem uma especificação “mínima” e o hardware recomendado para compra. Lideres inteligentes de projeto irão além até mesmo das especificações recomendadas de hardware, caso algo ocorra, pelo menos os fornecedores e seus clientes não estarão apontando seus dedos para as decisões de compra de hardware orientadas a baixo custo. Além disso, certifique-se de que todo o hardware e software comprados sejam compatíveis e testados uns com os outros. Você não quer que nenhum lado aponte culpados precocemente caso algo dê errado.
Às vezes o segredo está nos detalhes quando o assunto é comprar tecnologia. Por exemplo, caso um fornecedor diga que possui muita experiência com a execução do MySQL no Linux, tome cuidado em exigir que o MySQL funcione no Windows. O fornecedor pode dizer que pode fazê-lo, mas que pode não ter muita experiência com isso. Caso você desvie do que o fornecedor recomenda, certifique-se de obter a aceitação do fornecedor por escrito. Além disso, nunca é demais verificar com os clientes anteriores que compartilharam uma configuração semelhante a fim de saber o lado bom e o ruim de como as coisas ocorreram caso eles tenham se desviado, ainda que pouco, das especificações recomendadas.
Nº 6: Os testes estão em segundo plano
Os testes são essenciais para o sucesso de um projeto. Seja ele um teste de unidade (que testa uma faceta do sistema) ou testes integrados (que testa todos os componentes, incluindo sistemas de interface existentes). Os testes devem ser feitos pelos funcionários atuais junto com um plano de testes. O plano de testes deve incluir todos os depoimentos, passo a passo, que os testadores devem fazer. E você deve detalhar, antecipadamente, como deve ser a aparência dos resultados.
Os dados de teste e processos devem avaliar todos os cenários, incluindo os bons e os ruins. Às vezes, os resultados de dados ruins conhecidos são mais interessantes do que aqueles de um resultado desejado. Os testes devem incluir testes de carregamento para ver como o sistema e a rede responde a utilização pesada. Os testadores devem compreender os resultados esperados, e deve ser esperado que eles reportem todos os desvios.
Nº7: Não existe nenhum plano de recuperação no caso de uma falha
Apesar de nossos melhores esforços, os planos nem sempre ocorrem como esperado. Todo líder de projeto precisa saber qual será a aparência do resultado final – e quando será a hora de admitir a falha e começar novamente. Todo projeto deve ter um plano secundário de lançamento caso o fracasso se torne a única opção.
Muitos eventos de lançamento são orientados pela crença de que “nada pode dar errado”. Os lideres desses projetos muitas vezes falham em garantir que boas cópias de segurança sejam feitas e verificadas. Eles não desenvolvem protocolos para definir o sucesso, e nem esboçam antecipadamente qual seria a aparência de uma falha. Eles não preparam a equipe para o que fazer diante de um erro no lançamento. Muitos projetos completamente novos alcançam um obstáculo fatal apenas para descobrir que não podem voltar atrás, graças a um planejamento pobre.
Com algumas exceções, os projetos devem ter planos para falhas, e, quando o fracasso for grande demais, devem permitir o retorno para o sistema anterior. Claro, falhar é vergonhoso e ninguém quer ter planos para tal acontecimento. Mas não ser capaz de recuperar-se durante uma falha de serviço acaba com uma carreira.
Tornar a diretoria ciente de que você possuía um plano secundário e que seguiu ele até sua meta quando o fracasso ocorreu é uma forma de ganhar elogios. Deixar que um evento de inatividade perdure por muito tempo à medida que você explica para a administração que não existe uma forma de voltar e que o caminho à frente não tem uma aparência muito boa é uma conversa completamente diferente. Planeje obter sucesso, mas também possua um plano para o caso de um fracasso.
Nº 8: As recomendações dos especialistas foram rejeitadas sem que os resultados fossem testados
Existem pessoas que pedem por conselhos de especialistas e não dão ouvidos a eles, e então escolhem um caminho diferente – sempre. E depois reclamam quando algo não funciona corretamente.
Não seja essa pessoa. Não deixe que essa pessoa tome grandes decisões em sua equipe. Está tudo bem pedir por conselhos de especialistas e depois fazer algo diferente. Isso faz parte da natureza humana, e é muitas vezes o sinal de um bom líder. Apenas não o faça compulsivamente. Mais importante ainda, se você for contra as recomendações e o resultado não funcionar, não culpe o consultor.
Desviar das recomendações do fornecedor ou consultor significa testar os resultados de sua mudança antes de lançar o projeto. Até mesmo caso o fornecedor ou consultor concorde com seu desvio da recomendação deles, certifique-se de que a mudança seja testada. Muitos projetos falharam depois dos lideres de projeto “realizarem algumas pequenas mudanças” que deixaram os fornecedores e consultores profundamente contrariados. Você ficaria surpreso com quantos especialistas permanecem em silêncio em frente de clientes que parecem saber mais do que os experientes consultores. Todo mundo quer ser amigo. Todo mundo espera que funcione.
Não tenha esperanças. Teste. E dê ouvidos a seus especialistas na maioria das vezes.
Nº 9: A data de lançamento é em um final de semana ou feriado
Muitos lideres de projeto planejam eventos de lançamento para finais de semana ou feriados, devido as menores chances de interrupção de serviço para funcionários ou clientes. Enquanto louváveis, essas oportunidades também tendem a ser os momentos em que o suporte tecnológico é mais difícil de ser contatado. Você pode ter seu fornecedor primário no local, mas o suporte tecnológico terceiro pode estar fechado ou ocupado (e pode não estar retornando ligações em tempo hábil), e o mesmo pode ocorrer com sua equipe. Conversar com o especialista em base de dados pelo telefone enquanto ele está de férias com sua família nunca é a melhor opção.
Nº 10: As expectativas não foram definidas
Quando um novo sistema está substituindo um sistema antigo, é útil para todos compreender as novas expectativas. Como o novo sistema irá se comportar? O que mudou nas transações e nos tempos de transação? Para quem os usuários finais devem ligar caso encontrem problemas? Quando tempo a equipe de solução de problemas estará presente durante o lançamento? Um novo sistema sempre irá frustrar as pessoas, mas, caso você defina expectativas realistas e dê para as pessoas opções de suporte acelerado, os problemas tendem a sumir de modo mais rápido e você termina com clientes mais satisfeitos em pouco tempo.
Nº 11: Economia na formação
Não sei dizer quantos lideres de projeto irão descontar do orçamento de treinamento quando tiverem de encarar custos extras. Ou quantos líderes presunçosos alegam que o sistema é tão simples que os usuários não precisam de treinamento. Caso você escute, “treinaremos parte da equipe com metade das aulas e assim eles poderão treinar os outros”, ou “nossos usuários são muito bons em aprender, eles podem compreender este novo sistema em apenas alguns dias”, você saberá que está a caminho do fracasso. Não são apenas os usuários que precisam de treinamento, mas os lideres de projeto, os solucionadores de problemas e a equipe de funcionários do suporte. Esteja preparado para atrasar o projeto caso o treinamento apropriado não seja dado.
Assinar:
Postagens (Atom)