GOVERNANÇA, RISCO E CONFORMIDADE

Ao longo dos anos, a Tecnologia da Informação se tornou a espinha dorsal para o negócio de muitas empresas e deixou de ser uma opção, tornando-se um diferencial competitivo. Entretanto essa dependência exige muitos cuidados, tais como garantir que os investimentos em TI gerem valor ao negócio, que os processos de TI sejam eficientes e que a disponibilidade das operações seja mantida, além da necessidade de aderência aos processos contratuais, aos mecanismos regulatórios e à legislação vigente.

Para endereçar esses desafios, as empresas recorrem cada vez mais aos modelos e frameworks de Governança, Gestão de Riscos e Conformidade (Compliance) ou simplesmente GRC. Esses termos por muito tempo viveram em “ilhas”, como se cada um observasse o outro a partir da sua respectiva “praia”, e raramente uniam seus esforços, recursos, processos e sistemas para alcançar objetivos comuns. Felizmente isso vem mudando, pois tratar de GRC sob uma perspectiva integrada tem chamado a atenção de muitas empresas.

De acordo com o ITGI (IT Governance Institute), Governança é o conjunto de responsabilidades e práticas exercidas pelos executivos e pela alta direção da empresa com o objetivo de fornecer orientação estratégica, assegurando que os objetivos da companhia sejam alcançados e que os recursos sejam utilizados de forma responsável.

Existem padrões e guias internacionais de boas práticas de governança de TI que podem ser utilizados como referência, tais como: COBIT (Control Objectives for Information and related Technology), um framework de boas práticas de TI; ITIL (IT Infrastructure Library), um conjunto de melhores práticas para o gerenciamento de serviços de TI; ISO/IEC 27001, um padrão de sistema de gestão de segurança da informação, dentre outros.

A definição de Gestão de Riscos do Risk IT Framework, determina que essa atividade deve envolver todas as unidades de negócios da organização para prover uma visão abrangente de todos os riscos relacionados à TI. Uma estrutura corporativa de gerenciamento de riscos (Enterprise Risk Management) proporciona um maior alinhamento com o negócio, eficiência dos processos de TI, maior disponibilidade das operações com uma consequente redução de incidentes, tudo isso gerando valor ao negócio. Em empresas prestadoras de serviços, a gestão de riscos pode representar oportunidades de novos negócios.

Por fim, Conformidade é o ato de aderir e demonstrar adesão a leis e regulamentos externos, assim como a políticas e procedimentos corporativos. Controles internos devem ser implementados para garantir ainda a eficiência das operações e a confiabilidade dos relatórios financeiros. As “não-conformidades” custam caro, podem gerar impacto financeiro e afetar a imagem da empresa.

Uma pesquisa da Advanced Market Research com empresas nos Estados Unidos, estimou os investimentos em GRC, no ano de 2010, em US$ 29,8 bilhões, um crescimento de 3,9% em relação ao ano anterior.

Governança de TI, Gestão de Riscos e Conformidade não devem ser tratados como disciplinas isoladas pois a gestão centralizada dessas atividades é uma tendência irreversível. Além disso, GRC é parte integrante da gestão corporativa e proporciona o alinhamento estratégico com o negócio e a entrega de valor, além de uma melhor gestão dos recursos e do desempenho da TI.

MEGAWORK

A Megawork possui líderes que elaboram projetos com as melhores práticas de gestão. O grande desafio de quem desenvolve um sistema “sob medida” é ser capaz de analisar, entender, desenhar e documentar previamente as reais necessidades do cliente e traduzí-las para um novo modelo de software que proporcione vantagem competitiva. 

Basicamente, nossos processos consistem em diagnosticar as necessidades da organização e planejar, executar e controlar os projetos de maneira eficaz. Desta forma, aumentar as possibilidades de sucesso e conclusão das atividades conforme prazos, custos e escopo previamente estabelecidos.

Estas práticas de gerenciamento ajudam a aprimorar a capacitação dos nossos técnicos agregando conhecimentos e ferramentas para que possam atuar com eficácia em equipes de projetos em todos os níveis, além de criar ambiente para a implementação de uma Metodologia padronizada de Gerenciamento de Projetos, metodologia do Project Management Institute - PMI.

A gestão de projetos é um serviço que a Megawork oferece a seus clientes independente da plataforma tecnológica ou ambiente computacional, sempre atendendo aos requisitos de negócio e aos padrões tecnológicos da instalação.

CHAOS REPORT: COMO ESTA A TI NO MUNDO ?

Pesquisa da Standish Group, vale a pena ler até o fim.

Em 1986 foi publicado um paper comparando a construção de pontes com a construção de software, como premissa foi utilizado:

• Pontes normalmente são entregues no prazo, dentro do orçamento e “não caem”
• Softwares raramente são entregues no prazo ou dentro do orçamento. E normalmente eles tem bugs.

Uma das maiores razões para o sucesso na construção de pontes é o alto nível de detalhe “em momento de design”. O “design” é congelado e o contratante tem pouquíssima flexibilidade de mudanças. Todavia, no mundo de negócios atual, este “congelamento” pode não acomodar as mudanças de negócio necessárias pelas empresas. Portando, um modelo mais flexível deve ser aplicado.
Mas também há outro elemento primordial a ser analisado entre a construção de pontes e construção de software. A construção de pontes é feita a pelo menos 3.000 anos. Quando uma ponte caia, as causas da queda eram investigadas, documentadas e disseminadas para que ninguém cometesse o mesmo erro novamente. Isto raramente acontece no desenvolvimento de software, onde as falhas são muitas vezes tratadas como causas normais e rotineiras e em sua grande maioria, são ignoradas. Como resultado, continuamos a cometer os mesmos erros que tínhamos na década passada (muda a linguagem ou o dispositivo, mas o erro é o mesmo).
Neste sentido, o foco da pesquisa do The Standish Group foi identificar:

• As falhas dos projetos de software
• Os maiores fatores que influenciam na falha de projetos de software
• Os pontos chave que podem reduzir estas falhas

Os Estados Unidos gastam mais de 250 bilhões de dólares cada ano no desenvolvimento de aproximadamente 175.000 projetos de software. O custo médio de um projeto em uma grande empresa americana é de 2.3 milhões de dólares, para uma empresa média é de 1.4 milhões d dólares e 434 mil dólares para uma empresa pequena. E a grande maioria destes projetos falha. Os projetos de desenvolvimento de software estão no caos.
O estudo classificou os projetos em três tipos:

• Sucesso: Projeto dentro do prazo, dentro do orçamento e com boa parte do escopo
• Sucesso parcial: Projeto funcionando, mas entregue sem atender ou custo, ou esforço ou com o escopo parcial
• Fracassos: Projetos cancelados ou não utilizados

Sua última revisão (2009) mostrava que:

• 24% dos projetos fracassam
• 44% dos projetos são entregues com sucesso parcial
• E apenas 32% dos projetos obtêm sucesso.

Os principais fatores que ajudaram no sucesso dos projetos foram:

• Envolvimento do usuário: 15.9%
• Apoio executivo: 13.9%
• Declaração de requisitos clara e limpa: 13%
• Planejamento apropriado: 9.6%
• Expectativas realistas: 8.2%
• Milestones pequenos: 7.7%
• Equipe competente: 7.2%
• Propriedade: 5.3%
• Visão e objetivos claros: 2.9%
• Trabalho duro e equipe focada: 2.4%
  Outros: 13.9%

Os fatores que influenciaram os projetos de sucesso parcial foram:

• Falta de insumos do usuário: 12.8%
• Requisitos & Especificações incompletas: 12.3%
• Mudanças nos requisitos & especificações: 11.8%
• Falta de apoio executivo: 7.5%
• Ambiente tecnológico incompleto: 7.0%
• Falta de recursos: 6.4%
• Expectativas irrealistas: 5.9%
• Objetivos nebulosos: 5.3%
• Ciclos (tempo) irrealistas: 4.3%
• Novas tecnologias: 3.7%
  Outras: 23%

O estudo mostrou também que quanto maior o tamanho do projeto, maior a probabilidade de fracasso. As principais causas de fracasso são:

• Requisitos Incompletos: 13.1%
• Falta de envolvimento do usuário: 12.4%
• Falta de recursos: 10.6%
• Expectativas não realistas 9.9%
• Falta de apoio executivo: 9.3%
• Mudanças de requisitos: 8.7%
• Falta de planejamento: 8.1%
• Não precisa mais daquilo: 7.5%
• Falta de gestão da TI: 6.2%
• Analfabetismo tecnológico: 4.3%
• Outros: 9.9%

PDCA E CICLO DE VIDA DE PROJETOS

Metodologias e práticas de gestão de projetos utilizam, como uma das suas ferramentas, o ciclo gerencial PDCA. As letras que compõem a sigla PDCA vêm dos vocábulos em inglês: Plan (planejar), Do (executar), Check (verificar) e Action (agir corretivamente). A Figura detalha o ciclo PDCA.

Todo projeto possui um ciclo de vida durante o qual são realizados os processos gerenciais que englobam diversas áreas de atuação  (por exemplo, escopo, tempo, recursos, etc.). Os processos gerenciais, por sua vez, dividem-se em iniciação, planejamento, execução, controle e encerramento. 

A iniciação e o encerramento são específicos da área de projetos, mas os três processos intermediários (planejamento, execução e controle) apoiam-se no ciclo gerencial PDCA. Os processos do PDCA ocorrem em ciclos tendendo, de preferência, para uma espiral. Os resultados das ações de iniciação são utilizados como entrada para as ações a serem tomadas durante o planejamento. Os processos de controle ocorrem simultaneamente com os processos de execução e dependendo dos resultados da análise de execução feita no processo de controle, pode-se voltar a executar ações de planejamento, podendo ser reiniciado o ciclo com a incorporação da melhoria.

Em gestão de projetos, o PDCA engloba:

A. planejamento (P): o planejamento depende da fase de iniciação do projeto, uma vez que as atividades planejadas devem ser somente as necessárias para cumprir o escopo do projeto definido na proposta;

B. execução (D): treinar, se necessário, executar o planejado, gerenciar o projeto, documentar a execução, consultar o planejamento para as próximas atividades, acompanhar a qualidade dos produtos e atualizar o arquivo do plano do projeto no MS Project;

C. verificação (C): fazer reuniões periódicas, avaliar o executado em relação ao planejado,avaliar o desempenho do projeto, avaliar solicitações de mudança e rever o plano de riscos, se necessário;

D. ação (A): tomar as ações corretivas e fazer ajustes no planejamento, se necessário,encerrar o projeto com propostas de aproveitamento dos seus produtos do projeto e respectivos indicadores para acompanhamento dos resultados esperados.

Em projetos, considerando a singularidade de sua execução, pode ocorrer uma sobreposição entre os processos D, C e A para as atividades que nunca foram executadas antes.

Fonte : TCU, Manual de Gestão de Projetos

10 DICAS PARA DEFINIR O ESCOPO DO PROJETO

Definir o Escopo do Projeto é uma etapa de vital importância. Se não for feita da forma correta, o projeto estará fadado ao fracasso, uma vez que é o escopo que determina o que irá (e não irá) ser feito/produzido/entregue ao termino do projeto. Um escopo mal-estruturado levará inevitavelmente a falhas de cronograma e de orçamento, uma vez que os problemas decorrentes da má especificação se farão presentes e a equipe terá que achar caminhos alternativos para a execução do projeto. Por fim, um escopo mal definido resulta em um cliente insatisfeito, uma vez que o mesmo pediu X e recebeu Z, levando a uma insatisfação do executivo, do time do projeto e do gerente. O efeito cascata disso pode ser terrível, como uma caça-às-bruxas para determinar de quem foi a culpa, quando na verdade a culpa foi do escopo mal-definido.

Para evitar isso, algumas medidas muito simples podem ser adotadas, aqui vai uma lista de 10 dicas para serem usadas na hora de determinar o escopo de um projeto:

• Assegure-se de que todos sabem e entendem qual o objetivo do projeto e que haja consenso sobre o resultado final do mesmo;
• Ouça com atenção o que seu cliente descreve;
• Tente entender não o que ele lhe pede para fazer, mas sim o que ele precisa para resolver o problema que lhe apresenta;
• Descubra o que ele não quer. Muitas vezes um projeto não vai para frente por que o escopo foca em coisas que não deveriam estar lá;
• Estabeleça o que não vai ser feito no projeto enquanto o cliente ainda estiver disponível. Se ele pedir X e Y, mas você perceber que Z e W devem ser providenciados, mas somente W é da sua responsabilidade, deixe claro que Z está fora do escopo do projeto;
• Estabeleça o que será necessário para que o projeto seja atingido, defina os pressupostos, de forma que todos saibam de antemão quais as necessidades básicas do projeto antes que elas atrapalhem seu andamento;
• Seja realista quanto ao que pode ou não ser realizado, quanto mais “pé-no-chão” é o escopo, maior a chance de sucesso do projeto;
• Evite o GoldPlating. Se não faz parte do escopo do projeto, não adianta tentar agradar o cliente com aplicações/funções ‘firula’. Elas podem acabar acarretando em um atraso no cronograma;
• Não tenho medo nem pena de fazer perguntas. Pode parecer óbvio para você, mas se não estiver absolutamente claro, pergunte;
• Tenha o time de projeto (ou os gerentes dos mesmos) na mesa de reunião quando o escopo for definido, assim qualquer problema técnico ou dúvida operacional poderá ser sanada na hora, em vez de descoberta posteriormente, causando problemas para o projeto.

Isso não cobre todas as coisas que se pode fazer para assegurar um escopo coerente, realista e dentro das expectativas do cliente, mas deve minimizar a quantidade de problemas que costumam ocorrer durante a elaboração do mesmo. Usar templates também pode ser uma boa idéia, já que elas facilitam a visualização do conteúdo e servem como guia para o que deve ser observado no processo de definição do escopo.

CAMINHO CRÍTICO

Conhecendo e controlando o caminho crítico do seu projeto, além dos recursos atribuídos a tarefas críticas, você pode determinar quais tarefas podem afetar a data de término do seu projeto e se esse projeto terminará dentro do prazo.

Qual o caminho crítico ?

ABFCEHIL

ABFGJKL

CUIDADO COM PROJETOS NÃO PLANEJADOS

Pré-requisito:Antes de assumir responsabilidades, verifique se você tem competência para assumir uma tarefa.

Ponto importante:Saber ouvir. 

Ponto passivo:Sem comunicação não chegamos a lugar algum. 

Conclusão:Uma gestão de projetos bem sucedida é aquela possui equipes competentes que sabem ouvir, e principalmente, se comunicam entre as partes.