Sucessos e falhas em projetos de TI

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.

Chaos Report 1994 a 2008, por Standish Group

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:

Mobilidade ainda não combina com segurança

Houve um tempo — passado “remoto” da informática — em que notebook e smartphone (que era quase sinônimo de BlackBerry) era coisa cara, usada só por altos executivos, profissionais que realmente dependiam da mobilidade, e viciados em tecnologia. Hoje, existe uma profusão de notebooks, netbooks e smartphones para todos os gostos, necessidades e bolsos. Os notebooks vem inclusive tomando o lugar dos computadores desktop nas casas e nas empresas.

A principal inteligência de um celular “smart”, além das funções convencionais de um telefone celular, era lidar com correio eletrônico (e-mail). Atualmente, telefones celulares topo de linha são munidos de processadores e sistemas operacionais poderosos, cartões de memória com grande capacidade de armazenamento e conectividade total, se tornando verdadeiros computadores que se carrega no bolso.

O preço dos smartphones ainda é salgado em relação a um celular simples, mas tome-se o exemplo da Apple que induz uma fascinação no mercado fazendo um iPhone se tornar objeto de desejo de boa parte dos mortais, pelo simples fato de que “é muito legal”.

Caos da segurança

Com todo esse imenso poder dos dispositivos móveis, com custos cada vez menores e escala crescente em ritmo acelerado, vem o caos da segurança da informação.

Cada vez mais, altos executivos e funcionários em geral querem trabalhar remotamente e dispor de todos os recursos em qualquer lugar, pressionando as empresas a disponibilizar notebooks, redes sem fio (Wi-Fi, 3G etc.), acesso remoto e outros recursos de mobilidade corporativa. Querem usufruir dessa comodidade e poder, mas a TI tem que se virar para continuar garantindo segurança, controle e disponibilidade neste audacioso ambiente ilimitado e diverso.

Muitas empresas impõem restrições ao uso de notebooks e outros equipamentos pessoais e de prestadores de serviço dentro da rede corporativa, devido à dificuldade para as áreas gestoras de tecnologia da informação (TI) em garantir as políticas e mecanismos de segurança, o controle e os demais padrões corporativos nestes dispositivos que, além de móveis, são de propriedade e responsabilidade externas.

Quando se chega aos smartphones, então, a fronteira entre o particular e o corporativo fica ainda mais difusa e complexa. Se o CEO adquire um iPhone particular e quer acessar o e-mail corporativo através dele, até quando é razoável a TI dizer não?

Os riscos de vazamento de informação se multiplicam em escala exponencial diante de toda essa mobilidade. Se há redes sem fio ou acesso remoto, o controle para evitar acessos indevidos por invasores precisa ser redobrado.

Além disso, dispositivos móveis são mais suscetíveis a extravio, furto e roubo, e com eles se vai toda a informação contida, que tende a ser muito mais valiosa do que o próprio aparelho. Lembra-se do rebuliço gerado pelo furto de laptops da Petrobras com informações sigilosas em 2008?

Reflexões

Há como a TI garantir o uso de senhas, certificados digitais, biometria, criptografia, antivírus, firewall, VPN e outros recursos de segurança, controle e proteção da informação, de forma contínua, prática, efetiva e viável? E há como conscientizar e preparar os usuários para manterem sempre regras e procedimentos seguros neste mundo móvel? Em geral segurança anda na contramão da comodidade. E tem complexidade e custos, muitos custos.

Para os profissionais de gestão de tecnologia e de segurança das empresas continuarem sua reflexão — e preocupação, beirando o desespero — recomendo ler a série de matérias da IT Web no Especial smartphones, por Richard Dreger e Grant Moerschel, da InformationWeek EUA, 15/06/2010. As reportagens são oriundas do estudo sobre gerenciamento de dispositivos móveis e segurança da InformationWeek Analytics 2010.

ITIL, gerenciamento de capacidade e maturidade

Gerenciamento de Capacidade (capacity management) é um dos cinco componentes na área de Service Delivery do ITIL (V2) — Information Technology Infrastructure Library (conjunto de boas práticas em gerenciamento de serviços de TI). No ITIL V3, passou a ser organizado como um processo de Projeto/Desenho de Serviço (Service Design).

O trabalho deve ser de natureza proativa ao invés de reativa e responsável por garantir que as necessidades do negócio e definições de serviço sejam satisfeitas usando um mínimo de recursos computacionais.

Atividades de Gerenciamento de Capacidade incluem:

  • Monitoramento, análise, calibração e implementação de alterações necessárias em utilização de recursos.
  • Gerenciamento de demanda por recursos computacionais, o que requer compreensão das prioridades do negócio.
  • Modelagem para simular desempenho da infraestrutura e compreender as futuras necessidades de recursos.
  • Dimensionamento de aplicações para garantir que os níveis de serviço requeridos podem ser atingidos.
  • Gerenciamento da capacidade de armazenamento de dados.
  • Criação de um plano de capacidade (capacity plan) que documente a atual utilização de recursos e preveja necessidades, bem como custos de suporte, para novas aplicações e versões.
  • Construção do plano anual de crescimento da infraestrutura com subsídio de outras equipes.

Algumas referências básicas sobre o tema:

A empresa TeamQuest oferece, além de soluções para Gerenciamento de Capacidade ITIL, material informativo sobre Gerenciamento de Capacidade ITIL. Define inclusive um Modelo de Maturidade de TI em cinco estágios:

Nível 0: Caótico
Nível 1: Reativo
Nível 2: Proativo
Nível 3: Serviço
Nível 4: Valor

Best Management Practices – White Papers, parte do portal oficial da OGC sobre ITIL (e outros), traz bom conteúdo introdutório e correlações de ITIL com outros padrões, modelos e melhores práticas de governança.

Para saber mais:

A boa terceirização

Li um artigo do Correio Braziliense on-line, Contratar terceirizado já não é unanimidade — Empresas absorvem mão de obra avulsa e apontam uma nova tendência no mercado. Sindicatos dizem que o fenômeno ainda é discreto –, por Karla Mendes e Luciano Pires, publicado em 14/03/2010.

A matéria é interessante e foca recursos humanos terceirizados, mas remeteu minha atenção a um fenômeno recorrente.

De tempos em tempos terceirização — ou outsourcing para os adeptos à terminologia em inglês — é vista como a tábua da salvação ou panaceia para todos os males, alternando entre o oposto como buraco negro devorador ou bola de neve incontrolável.

Creio que terceirização, assim como quase tudo na vida, não deve ser colocada em termos extremos de tudo ou nada, paraíso ou inferno. A adequação e o sucesso  de terceirização dependem do que, porque e como terceirizar.

De acordo com os objetivos de uma organização, com seu nível de maturidade e com o cenário atual do mercado, a boa terceirização em geral deve:

  • Ser economicamente viável e vantajosa. O capital move a economia e o mercado. Dessa forma, o objetivo mais comum da terceirização costuma ser redução de custos. Em outros casos, pode representar um reequilíbrio orçamentário através da conversão de custos fixos e despesas com pessoal em custos com a contratação de serviços — nos órgãos públicos, por exemplo, a Lei de Responsabilidade Fiscal limita o percentual do orçamento destinado a pessoal. Mesmo que economia não seja o principal foco na opção por terceirização, deve-se avaliar a projeção de custos para garantir que antes de tudo ela seja economicamente viável e sustentável, com os custos sob controle ao longo do tempo.
  • Estar fora do core business do negócio. Definir e gerenciar o negócio principal de uma organização é algo que não faz sentido ser feito fora dela. Uma organização deve investir principalmente naquilo que é sua missão, aquilo que é seu maior domínio, que sabe e deve fazer melhor, que é seu diferencial competitivo. Atividades, recursos e necessidades comuns, secundários ou periféricos podem ser commodity disponível no mercado e providos na forma de serviço, e são estes os serviços passíveis de melhor terceirização.
  • Ser medida e remunerada por resultados e por qualidade. Nas contratações mensuradas em postos de trabalho (body shop) ou homem-hora, por exemplo, paga-se pelo meio, e não pelo fim. Faça analogia ao táxi cujo taxímetro cobra pela distância percorrida, não por chegar rapidamente ao destino, sendo este último o que realmente importa. Ao invés de terceirizar atendentes, terceirize atendimentos satisfatórios. Ao invés de terceirizar faxineiros, terceirize área limpa. Caso contrário, de nada adiantará uma aparente redução de custos se não forem obtidos resultados com qualidade; essa redução será mero corte, e não efetiva economia. O instrumento típico de medida e remuneração (e penalidades) priorizando resultados e qualidade é o ANS/SLA (acordo de nível de serviço / service level agreement).
  • Tirar proveito da economia de escala. Se sua organização deve prover um serviço de, digamos, manutenção de computadores para atender uma filial onde trabalham 20 funcionários em outra cidade, poderia se ver obrigada a ter custos fixos em manter toda uma estrutura de atendimento, logística e pessoal para este serviço na filial, e ficar em um dilema entre pagar por certa ociosidade ou correr o risco de não conseguir atender rapida e eficientemente. Um fornecedor que preste este serviço a vários clientes na cidade da filial tem seus custos fixos, incluindo infraestrutura e pessoal, compartilhados e rateados entre os clientes, dando-lhe condições de oferecer um serviço melhor a custos menores por cliente.
  • Permitir alocação de recursos sob demanda. A escala, além do rateio de custos fixos, também pode trazer outro benefício. O fornecedor pode manter uma margem de recursos de infraestrutura e de pessoal tal que possam ser rapidamente alocados e desalocados de forma dinâmica e sazonal entre seus clientes, na medida da necessidade momentânea de cada um. Os princípios de cloud computing (computação na nuvem) e virtualização dos provedores de data center representa bem este aspecto: estes fornecedores oferecem a possibilidade de se ampliar a capacidade de servidores de rede a um cliente de acordo com a demanda. Da mesma forma, um serviço de call center pode oferecer a alocação de mais atendentes em épocas de picos de atendimento, enquanto que para uma organização mantendo este serviço internamente implicaria na contratação ou demissão de pessoal nesses períodos, o que é bem mais complexo e às vezes inviável.
  • Trazer valor agregado e know how. Ao terceirizar determinado serviço, busca-se contratar um empresa especializada e altamente qualificada neste serviço e segmento de mercado, tal que o fornecedor tenha condições de agregar conhecimentos, capacidades, recursos, técnicas, inovações e melhoria contínua que dificilmente sua organização alcançaria prontamente ou seria capaz de manter tendo outro foco de negócios.

Por fim, é importante lembrar que terceirização é uma troca. Trocam-se os custos, complexidades, prós e contras da realização interna pelos de uma aquisição. Deixa-se de ter a execução interna do serviço, que passa a ser desempenhado pelo fornecedor. Por outro lado, o planejamento prévio à contratação se torna fator crítico de sucesso, e cria-se uma inevitável atribuição interna à organização: o gerenciamento da terceirização, envolvendo as responsabilidades pela contratação, fiscalização e acompanhamento regulares do serviço prestado e de sua efetividade.

Blogs sobre gestão

Fazendo um apanhado de blogs e comunidades sobre temas em gestão, eis o que obtive.

Gestão de projetos

Gestão de carreira e pessoas

Mais PMBOK e gerenciamento de projetos

Meu artigo PMBOK e Gerenciamento de Projetos foi amplamente revisado e agora está mais completo. A revisão anterior fora em março deste ano.

Passei a apresentar os conceitos de projeto, gerenciamento de projetos, e processo. O texto abordava uma série de características do gerenciamento de projetos, porém antes não trazia a definição desses conceitos básicos, importantes para quem está começando a aprender.

Para melhor sequência lógica dos assuntos no texto revisado, as áreas de conhecimento passaram a ser explicadas antes dos grupos de processo.

E elaborei uma nova figura mostrando, de forma tabular, a distribuição das quantidades de processos pelas áreas de conhecimento e grupos de processos. Essa figura permitiu ilustrar facilmente algumas características lógicas dos processos de gerenciamento de um projeto, que destaco no texto do artigo.

Ficaram de fora do artigo, agora, apenas dois tópicos que considero também relevantes ao gerenciamento de projetos: apresentar e entender as partes interessadas (stakeholders) de um projeto; e a compreensão do ciclo de vida de produtos e onde se insere neste o ciclo de vida do projeto. Futuramente pretendo incluir estes dois assuntos, e aí o artigo finalmente será uma introdução bastante abrangente.

MPS.BR atualizado e ampliado

O programa MPS.BR – Melhoria de Processo do Software Brasileiro, está em franca atualização e ampliação.

Com a atualização de seus guias ocorrida de agosto a outubro de 2009, agora há três novas partes nos Guias de Implementação. Além das Partes 1 a 7 que correspondem à implementação dos níveis de maturidade G a A, respectivamente, há três novas partes com orientações específicas para a implementação do Modelo de Referência MR-MPS: A Parte 8 é para organizações que adquirem software, a Parte 9 para Fábricas de Software, e a Parte 10 para Fábricas de Teste.

A aquisição de software é abordada pelo MPS.BR no Guia de Aquisição, atualizado em agosto de 2009, que descreve um processo de aquisição de software e serviços correlatos, baseado na Norma Internacional ISO/IEC 12207:2008.

Para saber mais:

GRC Brasil

Lançado novo Portal GRC Brasil, sobre Governança, Riscos e Conformidade (ou no original em inglês, Governance, Risk and Compliance), e com seções também sobre Pessoas e Referências Bibliográficas.

Entre os temas abordados, estão Carreira, COBIT, COSO, Gestão de Riscos, Governança Corporativa, Governança de TI, ISO 27001, ISO 38500, ITIL, Políticas de Segurança, ROI & TCO, Sourcing (Terceirização e Aquisições).

Dica do meu colega Luís Cláudio, autor do blog GR Tips.

Outras referências relacionadas ao tema:

PMBOK e Gerenciamento de Projetos – atualizado

Revisei meu artigo introdutório PMBOK e Gerenciamento de Projetos, que não sofria alteração desde a primeira revisão em 6 de maio de 2007.

Atualizei um diagrama, incluí a citação de outro (com o devido crédito ao seu autor Mauro Sotille) e fiz constar a nova Quarta Edição do Guia PMBOK. Detalhes a seguir.

Diagrama das Áreas de Conhecimento — A qualidade no centro

Quando concebi o diagrama que ilustra e interrelaciona as nove áreas de conhecimento abordadas pelo PMBOK, coloquei o Escopo no centro de um triângulo ladeado por Tempo, Custos e Qualidade. Minha crença até então era que o Escopo, ou seja, o que deve ser feito no projeto, era o elemento central que realmente interessava.

Hoje, transcorridos alguns anos e várias experiências em gerenciamento de projetos, vejo que o essencial é que todo projeto existe com um objetivo. Escopo é o que deve ser feito no projeto para atingir esse objetivo, mas não necessariamente se confunde com o objetivo em si.

Dependendo de restrições e condicionantes em fatores como disponibilidade de Prazo/Tempo, Orçamento/Custo, de Recursos Humanos e capacidade ou viabilidade de Aquisições, o Escopo pode ser afetado e negociado para se equilibrar com estes demais fatores, diminuindo ou mesmo aumentando, desde que o objetivo do projeto possa ser satisfatoriamente alcançado.

E aí ocorre a palavra chave: satisfatoriamente. A condição de satisfação do objetivo está essencialmente ligada à Qualidade.

A essência da qualidade pode ser entendida como o cumprimento satisfatório das necessidades e expectativas do patrocinador e demais partes interessadas, levando em consideração principalmente o balanceamento da chamada “restrição tripla” de escopo, tempo e custo do projeto.

Portanto, é a Qualidade que agora ocupa o centro da figura, pois ela em geral é decorrência do dimensionamento do triângulo Escopo – Tempo – Custos que a envolve, bem como dos insumos de RH e Aquisições, mantendo viáveis os níveis de risco e comunicações. Ou então há a situação recíproca: os requisitos de Qualidade necessários para a satisfação do objetivo do projeto determinam o dimensionamento dos outros fatores.

Os defensores da Qualidade Total e ISO 9000 também verão mais harmonia com “a qualidade no centro de tudo”.

Portanto, uma pequena mudança na figura, mas uma razoável evolução na compreensão e interpretação por trás dela.

Para saber mais:

Quarta Edição do Guia PMBOK

Em 31 de dezembro de 2008, o PMI lançou versões atualizadas de quatro de seus padrões globais, incluisive A Guide to the Project Management Body of Knowledge – PMBOK ® Guide — Fourth Edition. A versão em português brasileiro do Guia PMBOK 4ª Edição (Um Guia do Conhecimento em Gerenciamento de Projetos) foi publicada em outubro 2009 (o PDF já fora disponibilizado aos membros do PMI em junho).

Aproveito para resumir a seguir as principais diferenças da Terceira para a Quarta edições do PMBOK:

  1. Todos os nomes de processos agora estão no formato verbo-substantivo. Antes alguns nomes de processo seguiam este formato, como “Realizar o controle da qualidade”, enquanto outros usavam o substantivo da ação e foram padronizados, por exemplo: Planejamento da qualidade se tornou Planejar a qualidade, e assim por diante: “Controle” por “Controlar”, “Definição” por “Definir”, “Estimativa” por “Estimar” etc.
  2. O número de processos foi reduzido de 44 para 42. Dois processos foram excluídos, dois foram adicionados e seis foram reconfigurados em quatro processos na área de conhecimento em Gerenciamento das Aquisições do Projeto. A saber:
    • Eliminado 4.2 – Desenvolver a declaração do escopo preliminar do projeto, já que o termo de abertura do projeto contém vários dos objetivos preliminares e já que esses objetivos são elaborados na declaração de escopo.
    • O 4.7 – Encerrar o projeto foi renumerado e alterado para 4.6 – Encerrar o projeto ou fase.
    • 5.1 – Planejamento do escopo foi substituído por 5.1 – Coletar os requisitos.
    • 9.4 – Gerenciar a equipe do projeto mudou de um processo do grupo de Controle para o grupo de Execução.
    • Adicionado 10.1 – Identificar as partes interessadas.
    • 10.4 – Gerenciar as partes interessadas foi alterado para Gerenciar as expectativas das partes interessadas e passou do grupo de Controle para o de Execução.
    • 12.1 – Planejar compras e aquisições e 12.2 – Planejar contratações foram unificados como 12.1 – Planejar as aquisições.
    • 12.3 – Solicitar respostas de fornecedores e 12.4 – Selecionar fornecedores foram unificados como 12.2 – Realizar as aquisições.
  3. A fim de proporcionar maior clareza, uma distinção foi feita entre o plano de gerenciamento do projeto e os documentos do projeto usados para gerenciá-lo.
  4. Foi empregada uma abordagem padrão à discussão de fatores ambientais da empresa e de ativos de processos organizacionais.
  5. Foi empregada uma abordagem padrão à discussão de mudanças, ações preventivas e corretivas e reparos de defeitos.

Para saber mais:

Diagrama dos processos de gerenciamento de projeto

O artigo abordava resumidamente as nove áreas de conhecimento do PMBOK e os cinco grupos de processos do gerenciamento de projetos. Faltava porém fazer um breve visão geral dos processos em si, correlacionando-os com os grupos em que são organizados e com as respectivas áreas de conhecimento relativa a cada um.

Um diagrama do professor Mauro Afonso Sotille, da PM Tech Capacitação em Gerenciamento de Projetos, cumpre essa lacuna de forma simples, clara e brilhante. Assim, incluí a reprodução e referência de uma versão deste diagrama, já atualizada para a 4ª Edição do PMBOK. Muito obrigado e parabéns, caro Mauro!

Direitos autoriais e de uso

Contudo, termino este post com uma triste e indignada constatação de que os brasileiros na internet ainda não compreendem a seriedade e importância de respeito aos direitos autorais.

Há mais de 15 anos eu mantenho um web site onde escrevo e publico considerável volume de conteúdo, compartilhando conhecimento e informação com toda a internet.

Todo o material que crio em meu site e em meu blog está publicamente disponível, contudo, tanto no blog quando no rodapé de todos os artigos do site há uma simples e clara indicação dos direitos autorais e condições de uso:

© Márcio d’Ávila, mhavila.com.br, direitos reservados. O texto e código-fonte apresentados podem ser referenciados, distribuídos e utilizados, desde que expressamente citada esta fonte e o crédito do(s) autor(es).

A licença formal que escolhi para reger os direitos reservados é a simples e liberal Creative Commons BY-SA versão 2.5, cujos termos não são nada burocráticos, jurídicos ou incompreensíveis. Pelo contrário, são muito simples e claros em bom português:

Você tem a liberdade de:

  • Compartilhar — copiar, distribuir e transmitir a obra.
  • Remixar — criar obras derivadas.

Sob as seguintes condições:

  • Atribuição — Você deve creditar a obra da forma especificada pelo autor ou licenciante (mas não de maneira que sugira que estes concedem qualquer aval a você ou ao seu uso da obra).
  • Compartilhamento pela mesma licença — Se você alterar, transformar ou criar em cima desta obra, você poderá distribuir a obra resultante apenas sob a mesma licença, ou sob uma licença similar à presente.

E não é que ainda assim encontro na Internet reproduções de meus textos feitos com um descarado copiar-e-colar sem as duas coisas tão simples que peço: citar minha autoria e a referência à página original? Francamente!…

Só sobre este artigo, eis dois maus exemplos:

Comparando ITIL e ISO 20000

O interessante artigo A ITIL E A ISO/IEC 20000 – O que elas têm em comum?, por Luciene Rosa, publicado em 11 de janeiro no portal de conteúdo da empresa Módulo, aborda e correlaciona dois dos principais modelos amplamente reconhecidos para o Gerenciamento de Serviços de TI (GSTI): ITIL e ISO 20000.

ITIL — Information Technology Infrastructure Library — é um conjunto de melhores práticas aplicáveis a infraestrutura, operação e manutenção de serviços de tecnologia da informação (TI). Foi desenvolvido no final dos anos 1980 pela CCTA (Central Computer and Telecommunications Agency) e atualmente está sob custódia do OGC (Office for Government Commerce) da Inglaterra.

Já a NBR ISO/IEC 20000 — Tecnologia da Informação – Gerenciamento de serviços — é a primeira norma internacional que visa definir um padrão mundial para o GSTI, através da uniformização dos conceitos e da visão dos processos que o implementam. Oriunda do padrão britânico BS 15000, foi evoluída para norma internacional pelo ISO/IEC em 2005, e publicada em português no Brasil pela ABNT em 2008.

Ficou de fora do artigo citado o modelo COBIT — Control Objectives for Information and related Technology — publicado pelo IT Governance Institute (ITGI), Information Systems Audit and Control Association (ISACA), EUA, que tem foco na gestão dos serviços de TI, abordando aspectos como controle, segurança e governança nos domínios de planejamento e organização, aquisições e implementação, entrega e suporte, e monitoramento e avaliação.

Para saber mais: referências sobre Governança e Gerenciamento de Serviços de TI, por Márcio d’Ávila.