Tweet

Depois de uma ampla atualização em maio e de outra, mais leve, em junho, acrescentei agora em meu artigo PMBOK e o gerenciamento de projetos uma importante seção, sobre as Partes interessadas de um projeto.

Conforme citei em maio, esse era um tópico importante que faltava para cobrir os principais aspectos do gerenciamento de projetos.

Espero que o artigo agora esteja bastante completo para uma introdução abrangente, apresentando os conceitos e aspectos fundamentais de gerenciamento de projetos, voltado a iniciantes nesse tema. Ainda assim, o artigo buscou continuar didático, sintético e objetivo, cobrindo todo esse conteúdo em poucos tópicos e páginas de texto.

Tweet

Tweet

Segundo a Wikipedia, em 1964 Victor H. Vroom — canadense com PhD pela Universidade de Michigan e atual professor de Organização e Gerenciamento na Escola de Administração da Universidadede Yale, EUA –, desenvolveu a teoria da Expectativa, através de seus estudos das motivações por trás das tomadas de decisão. Sua teoria é relevante para o estudo da motivação em administração e gerenciamento, em especial na gestão de pessoas e talentos.

A Teoria da Expectativa (Expectancy Theory) propõe que uma pessoa decidirá se comportar ou agir de determinada maneira porque é motivada a selecionar um comportamento específico em detrimento de outros, devido ao que ela espera que o resultado do comportamento selecionado seja.

– Oliver, R. Expectancy Theory Predictions of Salesmen’s Performance. Journal of Marketing Research volume 11, p. 243-253, agosto 1974.

Elizeu Araujo, em seu artigo Teorias da Motivação, cita que para Eward Lawler, o modelo de expectativa baseia-se em quatro pressupostos:

• O Comportamento é determinado por uma combinação de fatores do individuo e do ambiente;
• Os indivíduos tomam decisões conscientes sobre seu comportamento;
• Indivíduos distintos têm necessidades, desejos e objetivos diferentes;
• Os indivíduos decidem entre alternativas de comportamento, baseados em suas expectativas de que um determinado comportamento levará a um resultado desejado.

Segundo Vroom, a motivação do indivíduo para escolher uma das alternativas de comportamento depende de três fatores:

• Expectativa de resultado do desempenho: Os indivíduos esperam certas consequências ou resultados de seus comportamentos, afetando decisões sobre como se comportam.
• Instrumentalidade: a percepção de que a obtenção de cada resultado está ligada a uma compensação. Fazendo uma escolha, os indivíduos tendem a escolher o nível de desempenho que pareça ter a máxima probabilidade de obter resultado satisfatório.
• Valência: o valor que cada indivíduo atribui ao resultado advindo de cada alternativa, o que se refere ao poder de motivar e varia de individuo para individuo. Ex.: para um indivíduo que valoriza o dinheiro e a realização, a transferência para um cargo com salário mais alto e em outra cidade pode ter uma Valência alta, enquanto que para um indivíduo que prioriza suas raízes e seu círculo de relacionamento na cidade atual, esse benefício terá sua Valência reduzida.

Araújo coloca didaticamente esses pressupostos na forma das seguintes reflexões, em que o indivíduo se questiona:

— Se eu fizer isso, qual será o resultado?
— O resultado vale o meu esforço?
— Quais as chances de alcançar o resultado que valha a pena para mim?

Esta teoria motivacional enfatiza a necessidade das organizações em relacionar as recompensas diretamente ao desempenho e em garantir que as recompensas providas são os benefícios merecidos e desejados por aqueles que recebem.

Os gestores de pessoas devem ter isso em mente ao estabelecer metas e recompensas e, desde o início, alinhar as expectativas junto aos talentos que integram e buscam motivar em suas equipes.

Para saber mais:

• Expectancy theory (em inglês), verbete na Wikipedia, a enciclopédia livre.
• Teorias da Motivação, por Elizeu Araujo, 2009-07-01, em WebArtigos.com, Administração e Negócios.
• A Teoria da Expectativa (Vroom), por Marcos Telles, 2005-01-24, fórum para reflexões sobre a aprendizagem on-line, sobre
  “A Teoria da Expectativa (Vroom)”, por Paula de Waal e Marcos Telles, 2004-06-28, em DynamicLab Gazette.
• Teoria da expectativa, in: Clima Organizacional: um fator de grande importância para a motivação do empregado, por Cíntia de Oliveira Heleno, monografia de conclusão do Curso de Graduação de Administração da Fasep – Faculdade Serrana de Ensino Superior, Brasília, DF, julho 2008, disponível em Scribd.
• Conceito da Teoria das Expectativas de Vroom, por Paulo Nunes, 2008-06-02, verbete na Enciclopédia de Gestão Knoow.net – Ciências Econômicas e Empresariais.
• Motivação dos Colaboradores, por Anderson Clayton, Luciano Pimentel e Maurício Roberto, monografia no curso de Organização, Sistemas e Métodos das Faculdades Integradas Campos Salles, sob orientação do Prof. Mauro M. Laruccia, novembro 2000.
• Teorias de Motivação: Um estudo de caso sobre a percepção das lideranças [PDF], por André Ferreira, Ana Alice Vilas Boas e Rodrigo Clebicar P. Mota Esteves, Universidade Federal Rural do Rio de Janeiro (UFRRJ) – ICHS/PPGEN, Seropédica, RJ, 2006.
• TEORIA DAS EXPECTATIVAS: uma análise da força motivacional dos funcionários do Banco do Brasil [PDF], por Antônio Alves Filho e Maria Aríete Duarte de Araújo, Revista FARN, Natal, RN, v. l, n. l, p. 57 – 68, julho/dezembro 2001.
• Expectancy Theory (Vroom) (em inglês), em 12 Manage.

Tweet

Tweet

Cito dois artigos sobre gerenciamento de projetos, com especial enfoque em projetos de tecnologia da informação (TI). Um é mais antigo, mas ainda perfeitamente atual e válido, e o outro bem recente.

Os 7 passos do gerenciamento de projetos
Por Fernando C. Barbi, 2008, em Microsoft TechNet Brasil.

1. Escolha e adote uma metodologia
2. Comunique-se: não é só o peixe que morre pela boca !
3. Defina o escopo do projeto e detalhe as atividades
4. Conheça os envolvidos e monte seu time
5. Desenvolva o cronograma junto com quem põe a mão na massa
6. Monitore os riscos e seja pró-ativo
7. Formalize o início e o encerramento do projeto

O artigo é aparentemente extenso, mas de leitura fácil e agradável. Barbi conclui assim:

Acima de tudo, gerenciar projetos é planejar e acompanhar a execução com “um olho no peixe e outro gato”. O gerente do projeto deve se manter alerta e flexível com os acontecimentos do dia-a-dia mas deve estar sempre se reportando ao plano inicial para não perder o controle. A principal qualidade do gerente de projeto é saber se comunicar bem com todos. Ele é o ponto focal das informações, nele convergem as informações que ele depois deverá processar e divulgar para todo o restante da equipe.

O segredo é envolver a equipe, cliente e fornecedores de tal forma que todos se sintam diretamente responsáveis pelo sucesso do projeto. Como diz aquele velho ditado caipira, “quando todos empurram na mesma direção, não há carroça que não saia do atoleiro”.

4 dicas para gerenciar o orçamento de projetos de TI
Revise sempre o bugdet e não seja pego de surpresa durante a execução de um projeto.
Por Jason Westland, da CIO/US, 01 de julho de 2011, em Computerworld Brasil.

1. Preveja o orçamento de forma contínua.
2. Revise a necessidade de pessoas envolvidas no projeto.
3. Mantenha a equipe informada.
4. Gerencie o escopo cuidadosamente.

Conclui o artigo:

O budget deve ser uma parte viva do projeto. Profissionais que observam cautelosamente os orçamentos durante todo o ciclo de vida dos projetos vão manter as partes interessadas e a gestão contentes e assim garantir o sucesso da implementação.

Tweet

Tweet

Lendo o artigo CHAOS Report: Métodos Ágeis Aumentam Taxa de Sucesso de Projetos, postado no Blog ScrumHalf em 11/02/2011, obtive os dados do mais recente relatório do Standish Group CHAOS Manifesto 2011, atualizado para dados sobre o sucesso e falha de projetos de TI da pesquisa realizada em 2010.

Em comparação com o relatório CHAOS Manifesto 20010, relatando a pesquisa realizada em 2008, a taxa de projetos rotulados como Sucesso aumentou de 32% para 37% enquanto a taxa de projetos rotulados como Fracasso diminuiu de 24% para 21%. A taxa de projetos com o rótulo de Deficit também decresceu de 44% para 42%.

A taxa de sucesso de 37% é a maior encontrada pelas pesquisas do Standish Group desde 1994.

Segundo o artigo, o Standish Group aponta quatro razões para a melhoria significativa encontrada em 2010 em relação a 2008:

1. Processos Ágeis: A utilização desses processos cresce a uma taxa de 22% CAGR (Compound annual growth rate). Hoje representam 9% de todos os projetos de TI e são adotados em 29% do desenvolvimento de novas aplicações. O instituto conclui que o crescimento da taxa de sucesso está diretamente relacionado ao aumento da adoção de metodologias ágeis.
2. Modernização: Esses projetos, que entre outros focam na conversão de código/banco de dados, tem taxa de crescimento anual menor do que a dos processo ágeis. Entretanto tem taxa de projetos rotulados como sucesso maior. O instituto conclui que isso acontece devido ao mecanicismo desses processos e de um ambiente relativamente mais homogêneo de perfil de profissionais.
3. Pacotes Empresariais: O número de novos projetos de implantação de ERP e CRM diminuiu. Como, segundo o instituto, consistem em projetos de grande risco com resultados questionados, a diminuição de novas implantações contribuiu para aumentar a taxa de projetos rotulados como sucesso.
4. Processos em Cascata: Consistem nos métodos tradicionais e já representaram quase 50% do número de novas implementações. Como crescem a 1% CAGR, sua utilização relativa diminuiu, contribuindo, assim, positivamente para a taxa de sucesso.

Estes dados me permitem autalizar o gráfico do artigo Sucessos e falhas em projetos de TI, postado exatamente um ano atrás. Agora ele fica assim:

No campo da Modernização, o Standish Group disponibiliza, na área de Amostra de Pesquisas (requer registro gratuito), o relatório NonStop Modernization (abril 2011) em que lista as prioridades de investimento em TI para 2011, The Standish Group’s annual Top 10 Areas of IT Investiments:

1. Modernização de aplicações (SOA, BPM, etc.)
2. Upgrade de infraestrutura (hardware, software)
3. Melhoria da segurança
4. Coud computing (SaaS, Utility Computing)
5. Desenvolvimento de novas aplicações
6. Capacitação da equipe
7. Disponibilidade de aplicações e sistemas
8. Conformidade e governança
9. Consolidação e otimização
10. Presença web e comércio eletrônico

E destaca os Três Conceitos e Seis Passos para a Modernização Contínua:

Conceitos:

1. Compreender seu projeto de modernização e o ambiente deste: a organização deve dominar o projeto de evolução que vai executar, compreender seus custos, riscos e benefícios, as diferentes opções e suas implicações, e deve ter um plano claro para seguir e guiar sua condução.
2. Refatorar: Standish Group estima que cerca de 80% dos recursos e funcionalidades de uma típica aplicação missão-crítica não são usados; deve-se, portanto, remover as partes não utilizadas antes de se migrar programas, evitando esforço inútil.
3. Modernizar a infraestrutura: atualizar hardware defasado e proprietário para sistemas blade comuns, aumentando a consolidação e trazendo mais simplicidade e flexibilidade.

Passos:

1. Modernize o banco de dados
2. Modernize a experiência do usuário
3. Modernize a aplicação
4. Modernize a disponibilidade
5. Modernize a segurança
6. Modernize a operação

Quanto aos processos ágeis, é interessante citar que o Manifesto Ágil completou 10 anos em 2011. Para abordar os desafios encarados por desenvolvedores de software, um grupo inicial de 17 metodologistas formou a Agile Alliance, em fevereiro de 2001. Este grupo formulou um manifesto para encorajar melhores maneiras de se desenvolver software, e baseado nesse manifesto definiu quatro valores e doze princípios que formam os fundamentos do movimento ágil.

Os quatro Valores do Manifesto Ágil:

• Indivíduos e interações acima de processos e ferramentas;
• Software funcionando acima de documentação abrangente;
• Colaboração com o cliente acima de negociação de contrato;
• Responder a mudança acima de seguir um plano.

Dentre as metodologias ágeis, o Scrum é um processo de desenvolvimento iterativo e incremental para gerenciamento de projetos e desenvolvimento ágil de software.

Para saber mais sobre o manifesto ágil e scrum:

• Agile Software Development Alliance (Agile Alliance).
• Manifesto for Agile Software Development (em inglês) e Manifesto para Desenvolvimento Ágil de Software (em português); veja também os Princípios por trás do Manifesto Ágil.
• Examining the Agile Manifesto, por Scott W. Ambler.
• Desenvolvimento ágil de software (em português) e Agile Software development (em inglês), verbetes na Wikipédia, a enciclopédia livre.
• Agile Manifesto 10th Anniversary series (em inglês), artigos publicados por InfoQ.
• Scrum Alliance.
• Scrum (em português) e Scrum (development) (em inglês), verbetes na Wikipédia, a enciclopédia livre.
• Scrum em 2 minutos, por Ivan Sanchez, 2007-02-07, no blog Coding Dojo Floripa – Desenvolvimento Ágil.
• Scrum: metodologia ágil para gestão e planejamento de projetos, em Improve It.

Aproveitando o assunto de projetos, também atualizei meu artigo introdutório PMBOK e Gerenciamento de Projetos, um dos mais acessados e citados do meu site, refinando as seções sobre o gerente de projetos e suas habilidades interpessoais, e também aquela sobre a instituição IPMA com sua filosofia e certificações.

Para saber mais:

• Chaos report: Como esta a TI no mundo?, por Washington Souza, 2010-08-09, Blog CMMI.

Tweet

Tweet

Sua empresa quer ou precisa elaborar uma política de segurança da informação, mas não sabe nem por onde começar? Eis aqui algumas dicas.

Créditos da figura: ISACA, 2009, An Introduction to the Business Model for Information Security (PDF).

Uma política de segurança da informação em geral é composta de diretrizes, normas e procedimentos que visam garantir confidencialidade, integridade e disponibilidade da informação (documental) que é produzida, recebida, utilizada, processada, armazenada e descartada por uma instituição. A gestão da segurança da informação envolve pessoas, processos, tecnologia e ambiente.

Deve também, idealmente, instituir um grupo ou comitê formal e permanente para centralizar o gerenciamento e orientação das atividades relativas a segurança da informação na organização. Para maximizar a autonomia e eficácia desse comitê gestor de segurança da informação, este deve estar ligado ao mais alto nível hierárquico de gestão da organização, como sua presidência ou comitê estratégico/executivo.

Não existe um modelo padrão de política de segurança da informação, porque esta tem que refletir os valores e a cultura da organização a qual se aplica, e levar em conta o negócio e o contexto em que ela está inserida. Ou seja, a política de SI deve ser construída sob medida para cada organização.

As normas ABNT e ISO/IEC relativas a segurança da informação fornecem conceitos e fundamentos essenciais que podem e devem embasar uma boa política de segurança da informação.

Mas a partir daí, as diretrizes, normas e políticas deve ser construídas em resposta a questões essenciais, como:

• Quais são os ativos e as informações de valor para a organização e seu negócio e que devem ser protegidos?
• Quais são os riscos aos quais a organização e suas informações estão submetidas, quais deles devem ser abordados e mitigados, e quais serão simplesmente aceitos?
• Quais são os aspectos e parâmetros relevantes para se definir o balanceamento entre: investimentos em segurança da informação versus valor dos ativos a serem protegidos e riscos de perdas envolvidos; ativos e serviços a serem protegidos versus vulnerabilidades e aspectos mais críticos a serem abordados na sua segurança; conveniência e facilidades versus proteção e controle.

O Sans Institute disponibiliza em seu portal uma série de documentos (PDF, em inglês) úteis para auxiliar na composição de uma política de segurança da informação, com foco em tecnologia da informação (TI):

• Security Policy Roadmap – Process for Creating Security Policies
• Information Security Policy – A Development Guide for Large and Small Companies
• Technical Writing for IT Security Policies in Five Easy Steps

Principais Normas ABNT NBR e ISO/IEC aplicáveis:

• Padrões em segurança da informação: Série ISO/IEC 27000 (ex 17799, BS 7799) – Gestão de Segurança da Informação.
• ABNT NBR ISO/IEC 27001 – Tecnologia da informação – Técnicas de segurança – Requisitos para Sistemas de gestão de segurança da informação.
• ABNT NBR ISO/IEC 27002:2005 – Tecnologia da informação – Técnicas de segurança – Código de prática para a gestão de segurança da informação.
• ABNT ISO Guia 73:2009 – Gestão de riscos – Vocabulário.
• ISO/IEC 13335-1:2004 – Information technology — Security techniques — Management of information and communications technology security — Part 1: Concepts and models for information and communications technology security management.
• ISO/IEC TR 18044:2004 – Information technology — Security techniques — Information security incident management.

Outras referências úteis:

• Livro: Política de Segurança da Informação – Guia prático para elaboração e implementação, por Fernando Nicolau Freitas Ferreira.
• Políticas de segurança da informação, verbete em Wikipédia.
• An Introduction to the Business Model for Information Security, ISACA. Business Model for Information Security – BMIS (requer registro gratuito).
• RFC 2196 – Site Security Handbook – (2) Security Policies.
• Segurança de Redes – Projeto e Gerenciamento de Redes Seguras, apresentação por Jivago Alves, em SlideShare.
• Decreto Presidencial nº 3.505, de 13 de junho de 2000 – Institui a Política de Segurança da Informação nos órgãos e entidades da Administração Pública Federal.

Tweet

Tweet

Mauro Segura é líder de marketing e comunicação da IBM Brasil e blogueiro. Estudioso do tema redes sociais nas empresas, ele aborda frequentemente o assunto em seu blog AQO – A Quinta Onda – Comunicação e Comportamento na Era da Sociedade Digital.

Sua visão pessoal a respeito dos executivos não blogarem é tão simplista e direta que ele até se desculpa se decepciona alguém: — Os executivos não blogam porque eles têm coisas mais importantes para fazer. Tão simples quanto isso.

Em junho do ano ano passado, o site norte-americano UBERCEO — que cobre a “vida” dos CEOs, Chief Executive Officers de empresas — afirmou que a maioria dos 100 principais executivos do planeta não frequenta rotineiramente as redes sociais.

Segundo a pesquisa do UBERCEO, os principais motivos são os riscos que as redes podem trazer para a reputação da empresa, pelo vazamento de informações estratégicas, pela falta de conhecimento em como lidar com as redes e pela paranoica percepção de que o acesso livre às redes gera improdutividade do funcionário.

UBERCEO pesquisou comunidades como Facebook, Twitter, LinkedIn e Wikipedia. O resultado é que apenas 2 CEOs tinham contas no Twitter, 13 deles tinham perfis no LinkedIn, 81% não tinham página pessoal no Facebook e nenhum deles tinha um blog.

O próprio Mauro Segura fez uma pesquisa junto a CEOs de algumas empresas — divulgada também na revista Época Negócios de novembro 2010 (ano 4, número 45) — e apontou Dez motivos por que os executivos não blogam:

1. Falta de tempo.
2. Medo de entrar em discussões polêmicas.
3. Percepção de que não é relevante.
4. Insegurança de até onde vai a conversa.
5. Insegurança para escrever.
6. Risco de imagem.
7. Vazamento de informação.
8. Medo de dizer que não deu certo.
9. Imagem perante os colegas executivos.
10. A comunidade não está preparada.

Observando a lista de motivos, eu ousaria complementar a constatação de Mauro Segura. Com tantos receios e desconhecimento apontados pelos executivos ante às mídias sociais da internet, seu potencial e seus impactos, eles realmente não priorizam tempo a elas.

Recentemente, Mauro Segura abordou outros aspectos do tema em seu artigo CEOs perdem tempo nas redes sociais, 2010-12-07, que comenta uma matéria de Lucy Kellaway em sua coluna do Financial Times, reproduzida no jornal brasileiro Valor Econômico. O mote aí foi a pronta interação do presidente da Starbucks no Reino Unido, Darcy Willson-Rymer, com um consumidor no Twitter.

Seja como for, creio que as empresas brasileiras ainda estão muito longe de aproveitarem ampla e plenamente o potencial das redes sociais não só como elemento integrador e propulsor da comunicação interna, mas também como um canal mais direto e intimista com seus consumidores, parceiros e sociedade em geral.

Na era da internet, essa é uma fronteira à parte a ser galgada pelas instituições.

Para saber mais, no blog A Quinta Onda, por Mauro Segura:

• Estudo: Mídias sociais nas empresas no Brasil, 2010-06-01, sobre o estudo da Deloitte chamado “Mídias sociais nas empresas – O relacionamento online com o mercado”.
• Os executivos não têm blog, 2010-06-07, sobre o estudo do UBERCEO.

Tweet

Tweet

O arquiteto, urbanista e professor Lúcio Costa (1902-1998), pioneiro da arquitetura modernista no Brasil, ficou conhecido mundialmente pelo projeto do Plano Piloto de Brasília. Contudo, cito o ilustre brasileiro em uma frase atribuída a ele, que para mim resume a razão de ser do gerenciamento de projetos:

“A única coisa do planejamento é que as coisas nunca ocorrem como foram planejadas.”

– Lúcio Costa

É consenso cada vez mais difundido que sem planejamento e sem monitoramento vem o descontrole. Empreitadas importantes e/ou grandes estão fadadas ao fracasso se não houver, além da execução em si, planejamento (antes) e controle (durante). Planejamento, execução, monitoramento e controle são elementos essenciais do gerenciamento de projetos.

Mas por que o gerenciamento de projetos, o planejamento e o controle são realmente necessários, e não apenas fazer-se o que precisa ser feito (a execução)? É exatamente porque, como bem disse Lúcio Costa, as coisas nunca ocorrem como foram planejadas. A vida, as pessoas, a sociedade, o mercado, o ambiente são cheios de incertezas e imprevistos, falhas e mudanças.

É possível saber exatamente quanto tempo cada pessoa tem de vida? Quando ficará doente? Quando conhecerá um grande amor? Quando mudará de emprego? Não. E quando choverá? E a chuva causará algum prejuízo? Quando será a próxima recessão econômica? E a próxima onda de prosperidade? Quando a bolsa de valores vai subir ou descer?

Além disso, pessoas são subjetivas, manhosas e — verdade seja dita — imperfeitas. E únicas: cada um tem sua personalidade, suas qualidades, defeitos, forças, fraquezas, crenças, medos, interesses, objetivos. Pessoas mudam de ideia, de opinião, de expectativa, até de humor, a todo momento.

Isso sem falar nos desafios da comunicação. A transmissão de ideias, conhecimentos e informações é uma arte. Veja a grande lição que traz a brincadeira do “telefone sem fio”. Passe uma simples frase por diversas pessoas e veja como ela pode se distorcer rapidamente.

Uma pessoa pode pensar uma coisa, falar outra e ainda ser compreendida de uma terceira forma diferente. Já viu aquela famosa tirinha de humor sobre as idiossincrasias de comunicação no desenvolvimento de software?

“A comunicação não é aquilo que falamos. A comunicação
é aquilo que é percebido, aquilo que é decodificado pelas outras pessoas”.

– Reinaldo Passadori

Se não houver planejamento e controle, os riscos e incertezas, os eventos imprevistos e as falhas vão ocorrendo a cada dia, levando ao gradativo desvio de rota e ao insucesso.

Gerenciamento de projetos existe para traçar, divulgar, monitorar e corrigir a rota dos projetos, tratando questões, riscos, incertezas, imprevistos, falhas e mudanças que surgem, sempre mantendo as partes interessadas informadas e gerenciando suas expectativas, de forma a garantir que cada projeto (uma tarefa ou empreitada a realizar) seja cumprido e atinja seu objetivo com sucesso.

Para saber mais:

• PMBOK e Gerenciamento de Projetos, por Márcio d’Ávila.
• Referências sobre gestão de projetos e processos, estratégia e governança.

Tweet

Tweet

Lendo no blog da consultora Patrícia Inêz, PMP, o artigo Venkatraman e os Projetos de Implantação de ERP, aprendi mais um pouco sobre alinhamento estratégico em TI.

O Modelo de Alinhamento Estratégico de TI proposto por Henderson e Venkatraman (1993) correlaciona os benefícios obtidos pelo uso de tecnologia da informação, com o grau de transformações ocasionados nos negócios da organização.

Existem os níveis de impacto evolucionário, que trazem melhoria e integração dos processos internos existentes, e os níveis considerados revolucionários, isto é, aqueles que implicam desde uma efetiva reengenharia até chegarem a impactar a redefinição do escopo dos negócios ou da atuação da organização (empresa ou instituição) em questão.

Referências principais:

• IT-Enabled Business Transformation: From Automation to Business Scope Redefinition (em inglês), por N. Venkatraman, MIT Sloan Management Review, vol. 35, n. 2, p. 73, 1994-01-15. Artigo em formato PDF.
• Strategic alignment: leveraging information technology for transforming organizations (em inglês), por J. C. Henderson e N. Benkatraman, IBM Systems Journal, v. 32, n. 1, p. 4-16, 1993.
• Strategic alignment: a model for organizational transformation through information technology, por J. C. Henderson e N. Venkatraman, Massachusetts Institute of Technology (MIT) Sloan School of Management, 1990. Artigo em formato PDF, no MIT. In: Transforming organizations, por Thomas A. Kochan e Michael Useem, cap. 7, 1992. Também In: Information technology and the corporation of the 1990s: research studies, por Thomas John Allen e Michael S. Scott Morton, cap. 9, Oxford University Press US, 1994.

Agora vou me debruçar a aprender mais a respeito:

• Metodologias COBIT e ITIL e as perspectivas do Modelo de Alinhamento Estratégico de TI [PDF], por Gilberto Zorello, Universidade de São Paulo (USP), XII SIMPEP – Bauru, SP, Brasil, 07 a 09 de novembro de 2005.
• Assegurando o alinhamento estratégico da tecnologia de informação e comunicação: o caso das unidades de refino da Petrobras, por Marcos Villas, Marcus Fonseca, T. Diana L. v. A. de Macedo-Soares, Revista de Administração Pública, vol. 40 nº 1, Rio de Janeiro, Jan./Feb. 2006, ISSN 0034-7612. Artigo em formato PDF, em SciElo.
• Alinhamento Estratégico da Utilização da Internet e do Comércio Eletrônico: os Casos Magazine Luiza e Fleury [PDF], por Amarolinda I. Costa Zanela Saccol, RAC, v. 9, n. 2, Abr./Jun. 2005: p. 59-80.
• Alinhamento Estratégico: Tecnologia da Informação e Negócio [PDF], por Prof. Dr. Fernando José Barbin Laurindo e Prof. Dr. Marcelo Schneck de Paula Pessôa, Departamento de Engenharia de Produção – Escola Politécnica da USP, para a disciplina de Gestão da Tecnologia da Informação, 2003.
• Alinhamento estratégico na gestão de projetos de TI [PDF], por Tatiana Ghedine, Anais do I Congresso de Estratégia, Curitiba, 2003.
• Uma Abordagem para Definição de Processos de Gestão e Monitoração de Outsourcing em Tecnologia de Informação baseada em Indicadores, por Cristina Coelho de Abreu Pinna, Fernando José Barbin Laurindo e Marcelo Schneck de Paula Pessôa, Revista Espacios, vol. 24, nº 3, 2003.
• Strategic Alignement Business and IT – Vekatraman (em inglês), Value Based Management.net.

Tweet

Tweet

Qualidade de software é um tema que vem sendo abordado e evoluído há muito tempo em engenharia e arquitetura de software, tanto em relação à qualidade do processo (da concepção à construção e à manutenção) quanto em relação à qualidade do produto, o software em si.

Nas décadas de 70 a 90, organizações internacionais de normatização e padronização — como ISO/IEC, ANSI, IEEE e outros — definiram qualidade de produto como:

A totalidade dos recursos, aspectos e características de um produto ou serviço que suportam a sua capacidade de satisfazer os requisitos dados, as expectativas e as necessidades explícitas e implícitas.

Em seu estudo sobre qualidade de software, Software Quality: Definitions and Strategic Issues (PDF, abril 1996), o pesquisador Ronan Fitzpatrick propõe uma visão mais moderna e ousada de qualidade do produto de software, definindo assim:

Qualidade de software é a medida em que um conjunto definido pela indústria de características desejáveis são incorporadas em um produto, de modo a aprimorar seu desempenho durante sua existência.

O Modelo de Qualidade de Software proposto por James A. McCall e outros, em 1977, foi um dos primeiros largamente difundidos neste campo. Ele organiza os critérios de qualidade de software em três pontos de vista, a saber:

• Operação: características relativas ao uso do produto.
• Revisão: capacidade do produto ser modificado e evoluído.
• Transição: adaptabilidade a novos e diferentes ambientes.

Os critérios de qualidade elencados no Modelo de McCall em cada ponto de vista estão listados na tabela a seguir.

Atualmente existem outros modelos de avaliação da qualidade do produto de software, em especial o padrão internacional de engenharia de software ISO/IEC 9126, que trata da Qualidade do Produto. A norma se divide em quatro partes, sendo a primeira uma visão geral do modelo de qualidade, e as outras três, os grupos de métricas definidas para este modelo:

• Parte 1: Modelo de qualidade.
• Parte 2: Métricas externas.
• Parte 3: Métricas internas.
• Parte 4: Métricas de qualidade em uso.

Qualidade externa diz respeito ao produto final como percebido pelo usuário, enquanto qualidade interna se refere à estrutura e às características do produto em seu projeto e construção.

Mais recentemente, desde 2005, as normas ISO/IEC 9126 e a série ISO/IEC 14598, de avaliação de produto de software, tem sido integradas na nova Série de normas ISO/IEC 25000 – Software Engineering — Software product Quality Requirements and Evaluation (SQuaRE), que tem seu núcleo principal composto por cinco divisões:

• ISO/IEC 2500n – Divisão Gestão da Qualidade;
• ISO/IEC 2501n – Divisão Modelo de Qualidade;
• ISO/IEC 2502n – Divisão Medição da Qualidade;
• ISO/IEC 2503n – Divisão Requisitos de Qualidade;
• ISO/IEC 2504n – Divisão Avaliação da Qualidade.

Além deste núcleo principal, o SQuaRE contempla extensões, que tratam de temas específicos, como ISO/IEC 25051, SQuaRE Requisitos para qualidade de produtos comerciais de prateleira (Commercial Off-The-Shelf – COTS), e ISO/IEC 2506n, SQuaRE Common Industry Format (CIF) para usabilidade.

Os critérios de qualidade no Modelo de McCall são muito similares aos preconizados por outros modelos para classificação de atributos de qualidade de software, como o FURPS+ (Robert Grady e Deborah Caswell, HP, 1987-1992) e o da própria ISO/IEC 9126, quanto a requisitos não funcionais:

.

Vale ressaltar que qualidade do software, abordada aqui, se entende por qualidade do produto de software em si, o que é distinto de qualidade do processo de software, que diz respeito à qualidade das atividades e forma pelas quais se produz software.

Para saber mais:

• Factors in Software Quality (PDF, em inglês), por McCall, Jim A.; Richards, Paul K.; Walters, Gene F. Relatório técnico final da General Electric Co. (GE), Sunnyvale, CA, EUA, novembro 1977. Volume I. Concepts and Definitions of Software Quality ; Volume II. Metric Data Collection and Validation ; Volume III. preliminary Handbook on Software Quality for an Acquisition Manager.
• Modelo McCall, 14 de maio de 2009, no blog Engenharia de Software.
• McCall’s Software Quality Checklist (PDF, em inglês), material de aula da disciplina CSE3308 Software Engineering: Analysis and Design, 2005, Monash University, Austrália.
• Referências sobre Produto de Software: Qualidade, Métricas e Teste, Engenharia de Software, Arquitetura de Software e sobre Maturidade e Qualidade de Processo de Software, por Márcio d’Ávila.
• Verbetes: Qualidade de software, Software quality (em inglês), em Wikipédia.
• Normas de Qualidade nos Processos de Desenvolvimento de Software (PDF), por prof. Ricardo J. Machado, Ph.D., Portugal, maio 2006.
• Software Quality Attributes; ISO 9126-1; e outros artigos sobre qualidade de software; em SQA.net – Software Quality Assurance.
• A Software Quality Model and Metrics for Identifying Project Risks and Assessing Software Quality (em inglês), por Lawrence E. Hyatt, NASA, e Linda H. Rosenberg, Ph.D., Unisys, NASA Goddard Space Flight Center, artigo apresentado na 8th Annual Software Technology Conference, Utah, EUA, abril 1996.
• Qualidade em Sistemas de Informação (PDF), Texto de apoio do Instituto Superior Miguel Torga, Portugal, dezembro 2002.
• Engenharia de Software – INE 5322 – Aula 3: Qualidade do produto de software (PDF), por Walter de Abreu Cybis, abril 2007, Universidade Federal de Santa Catarina (UFSC).
• Qualidade de Software (PDF), parte da Disciplina MC626, por Prof. Ricardo Anido, Universidade Estadual de Campinas (Unicamp). Adaptado de notas de aula da Prof. Eliane Martins.
• Software Quality (PDF, em inglês), 2005-2006, em Scribd.
• Qualidade do Produto de Software (PDF), por Ana Cervigni Guerra, Centro de Pesquisas Renato Archer (CenPRA) Tecnologia da Informação, Divisão de Qualificação em Software – DQS, junho 2009.
• O modelo SQuaRE, por Danilo Scalet, Q4E, 2008-03-02, no blog Qualidade de Software e Serviços.
• ISO/IEC 25000:2005 Preview (PDF), IEC – International Eletrotechnical Commission. Versão completa em ISO/IEC 25000:2005 – Software Engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Guide to SQuaRE, ISO – International Organization for Standardization.
• Verbete: ISO/IEC 9126, em Wikipédia.
• FURPS+, por Fabrício Ferrari de Campos, 2008-07-10, no blog QualidadeBR.
• Verbete: FURPS (em inglês), em Wikipedia.
• The FURPS+ System for Classifying Requirements. In: Capturing Architectural Requirements (em inglês), por Peter Eeles, IBM, 2005-11-15.

Tweet

Tweet

Há 16 anos, o Standish Group estuda projetos de TI. Ao longo desse tempo, a pesquisa CHAOS já estudou mais de 70 mil projetos de TI realizados.

O CHAOS Report é frequentemente citado em artigos e apresentações sobre gerenciamento de projetos de TI. Essa pesquisa classifica o resultado de cada projeto de TI em uma destas três situações:

• Bem sucedido: O projeto é concluído dentro do prazo e orçamento planejados, com todos os recursos e resultados originalmente especificados.
• Deficitário: O projeto é concluído e operacionalizado, mas com atraso, acima do custo estimado ou com menos recursos e resultados que o especificado.
• Falho: O projeto é cancelado antes de ser concluído ou nunca é implementado.

A evolução dos percentuais de cada resultado, nas pesquisas CHAOS de 1994 até 2008, está representada no gráfico a seguir.

Há quem critique os critérios utilizado pelo Standish Group. No artigo The Rise and Fall of the Chaos Report Figures, por J. Laurenz Eveleens e Chris Verhoef, Universidade Vrije de Amsterdam, 2009-09-04, publicado na IEEE Software, vol. 27, num. 1, p 30-36, jan/fev 2010, os autores afirmam que “seus estudos apontam que as definições de sucesso e de desvio de projetos tem quatro problemas principais: são ambíguas, unilaterais, pervertem a prática de estimativa, e resultam em números pouco significativos“.

Contudo, o Standish Group tem repetido as pesquisas de forma consistente a cada dois anos desde 1994. Desta forma, os resultados apresentados no Chaos Report são, no mínimo, um referencial histórico para análises e considerações sobre a evolução do sucesso em projetos.

Um paralelo com o Guia PMBOK e processos estratégicos

Interessante notar que o Instituto de Gerenciamento de Projetos (PMI) lançou a primeira versão oficial do Guia PMBOK em 1996. Este Guia pode ser considerado um marco na formalização e ampla divulgação dos conceitos e das melhores práticas em gerenciamento de projetos, e vem contribuindo para a profissionalização e evolução da atividade de gerenciamento de projetos em todo o mundo.

O Guia PMBOK tem sido atualizado e publicado pelo PMI em ciclos de quatro anos, com novas edições tendo sido lançadas em 2000, 2004 e 2008, inclusive com traduções em português e diversos outros idiomas.

De 1994 para 1996, o sucesso em projetos medido no CHAOS Report teve um considerável salto positivo, de 16% para 27%. Igualmente, a partir de 1996, a taxa de sucessos cresceu pouco, mas até 2002 a taxa de fracassos decaiu consideravelmente, de 40% chegando a 15%.

A disseminação dos conceitos e práticas de planejamento e controle no gerenciamento de projetos, com a participação de organizações profissionais como o próprio PMI (de origem americana), o IPMA (de origem europeia) e outras, neste período, provavelmente contribuiu para o aumento do sucesso e redução do fracasso em projetos.

A oscilação de sucessos e fracassos desde 2002 deve levar em conta as crescentes abrangência, complexidade e criticidade dos projetos de TI, com a tecnologia sendo impelida a atuar imersa e alinhada cada vez mais no cerne dos processos de trabalho e das estratégias institucionais.

Fatores críticos de sucesso

Mesmo que o paralelo apresentado seja interessante e coerente, seria um tanto simplista tentar resumir a poucos pontos os determinantes da evolução no resultado dos projetos.

O próprio Standish Group aponta um conjunto mais consistente de fatores críticos de sucesso para projetos de TI:

• Envolvimento efetivo e positivo dos usuários.
• Apoio da alta gestão, ou patrocínio executivo.
• Objetivos de negócio claros, bem definidos.
• Maturidade emocional das partes envolvidas (stakeholders), controlando as “Cinco Sinas Mortais” no gerenciamento de projetos: ambição excessiva, arrogância, ignorância, abstinência e fraudulência.
• Otimização, visando obter o máximo de valor para o negócio com o mínio de riscos.
• Processos ágeis, com desenvolvimento iterativo.
• Expertise em gerenciamento de projetos, onde aí entra a importante contribuição do Guia PMBOK e das organizações profissionais de gestão de projetos.
• Equipe capacitada, consistindo na habilidade de adquirir, gerenciar e controlar os recursos certos no momento certo, lidando com turnover, bem como desenvolver e manter competências.

Para saber mais:

• Referências sobre gerenciamento de projetos, programas e portfólio.
• PMBOK e Gerenciamento de Projetos, por Márcio d’Ávila, atualizado em 4 de maio de 2010.
• Sample Research do Standish Group (em inglês, requer registro gratuito), dando acesso ao primeiro CHAOS Report (1994) e ao relatório Extreme CHAOS de 2001, entre outros recursos.
• The Standish Group Report CHAOS (1994) [PDF], reproduzido (em inglês, sem os gráficos) sob permissão por ProjectSmart.co.uk.
• The Rise and Fall of the Chaos Report Figures [PDF] (em inglês), por J. Laurenz Eveleens e Chris Verhoef, Vrije Universiteit Amsterdam, fevereiro de 2010. Ver resenha em Agile Blog.
• Chaos Report 2009, novas informações, velhos problemas!, por André Dias, 7 de julho de 2009, em MSDN Blogs.
• Gerência de Projetos – CHAOS Report [PDF], por Dr. Antão Moura, DSC/UFCG.
• The Software Reality Check – Diagnosing Software Projects in Crisis [PDF] (em inglês), white paper por Architect Solutions, 2009.

Tweet