Gestão de Projetos Tecnológicos

Prévia do material em texto

PEDRO FASCINA CASARIN
Gestão de projetos 
tecnológicos
32
Tempo, riscos e fatores de impacto em projetos
2
UNIDADE 2
TEMPO, RISCOS E FATORES DE 
IMPACTO EM PROJETOS
INTRODUÇÃO
Como já estudamos, a gestão de projetos tecnológicos é uma disciplina essencial para 
que se consiga ter uma bagagem no desenvolvimento de novas implantações. Nesse 
contexto, necessitamos introduzir novos conceitos para aprimorar nosso aprendizado, o 
tempo, por exemplo, associado a um cronograma robusto, desempenha um papel fun-
damental e tem impacto direto nos prazos de entrega e no alcance dos objetivos finais 
do desenvolvimento. A gestão deste recurso, por sua vez, é fundamental, pois permite 
que a equipe de projetos desempenhe as tarefas previamente estabelecidas de forma 
fluida e com robustez.
Associa-se este importante conceito com a certeza de que todo projeto carrega consigo 
riscos inerentes, como uma falha na segurança de um sistema, ou um atraso na entrega 
de um componente para um servidor, tendo, assim a análise de riscos. 
A análise de riscos faz-se crucial na avaliação e mitigação de tais riscos, ao antecipar e ge-
renciá-los, as equipes de projetos podem adotar medidas proativas para minimizar as ame-
aças e garantir um ambiente mais seguro e confiável para o desenvolvimento do projeto.
Durante esta unidade, iremos abordar, compreender e aplicar práticas eficazes de ge-
renciamento do tempo, gestão do ciclo de vida, análise de riscos e exploraremos a 
correlação entre tempo e risco, além de discutir como executar e entregar projetos de TI 
com sucesso, obtendo melhores resultados e garantindo a satisfação de seus clientes, 
com análises assertivas.
1. O QUE É O TEMPO, E SEU RELACIONAMENTO COM 
METODOLOGIAS DE PROJETOS EM TI
Antes de iniciarmos, necessitamos entender que a palavra “tempo” tem sua origem 
no latim “tempus”, no passado, era utilizada para se referir ao conceito de estações, 
períodos e ocasiões específicas. Ao longo dos séculos, seu uso foi sendo incorporado 
e considerado em diferentes idiomas, incluindo o nosso, mantendo seu significado ori-
ginal relacionado à noção de duração e período. 
Mas não só o prazo de entrega se associa a este conceito, o tempo é uma dimensão 
fundamental no gerenciamento de projetos tecnológicos. Ele se refere à duração e à 
sequência de atividades ao longo do life cycle (ciclo de vida) do projeto. Nas metodologias 
mais comuns, como as estudadas, o tempo é um dos principais elementos a serem 
considerados e gerenciados.
33
2
Gestão de projetos tecnológicos
U
ni
ve
rs
id
ad
e 
S
ão
 F
ra
nc
is
co
Seu relacionamento com projetos se dá de algumas maneiras, o relacionamento entre o 
tempo e as metodologias de projetos é um desses exemplos, sua correlação se faz no 
uso de abordagens adaptativas, com ênfase na iteração e a priorização de atividades 
com definição de entregas mais curtas, permitindo uma maior flexibilidade na adapta-
ção do cronograma de acordo com as necessidades e mudanças do projeto. Portanto, 
uma tarefa mais curta, se atrasada, por exemplo, pode ser compensada por o adianta-
mento de uma longa, sem um impacto tão grande no cronograma previamente definido.
Associada a esta ideia, o planejamento temporal fornece uma base robusta para a de-
finição e organização das atividades logicamente, esta organização envolve a criação 
de um cronograma com marcos, entregas e início bem definido. Em resumo, o tempo 
é um elemento essencial nas metodologias de projetos, pois influencia diretamente a 
organização, o controle e o sucesso do projeto como um todo.
1.1. TÉCNICAS PARA ELABORAÇÃO DE UM CRONOGRAMA
Já entendemos que o tempo é um fator-chave para a elaboração de um cronograma, 
visto que ser assertivo pode resultar em um resultado positivo para o projeto ou tarefa 
associada, neste caso, para nos auxiliar em sua definição, elaboração e aplicação, po-
demos utilizar algumas técnicas para o aprimoramento das definições iniciais ou lista de 
atividades. Observe as técnicas abaixo para elaboração e suas explicações adaptadas 
segundo o PMI (2021): 
Análise de Decomposição: baseia-se em dividir o projeto em atividades menores e mais 
gerenciáveis com o intuito de evidenciar os principais entregáveis do projeto e, em seguida, 
dividir as demais entregas dentro destes tópicos gerais. Essa decomposição é feita de forma 
hierárquica, ou seja, as atividades são subdivididas em subtarefas até que sejam atingíveis no 
contexto do projeto. Sua principal vantagem é que ela permite uma melhor compreensão do 
trabalho envolvido em cada atividade, facilitando tanto a gestão de recursos quanto a definição 
dos responsáveis e partes impactadas por cada tarefa. 
Análise de Rede: envolve a criação de um diagrama de rede base, como um diagrama de 
setas (DS) ou diagrama de precedência (DP), para representar as atividades do projeto e 
suas relações de dependência. Isso ajuda a visualizar a sequência lógica das tarefas e iden-
tificar o caminho crítico do projeto.
Quando usamos o Diagrama de Setas (DS), as atividades são representadas por setas, 
e os pontos de chegada (Nós) representam os eventos, que são pontos de início ou tér-
mino das atividades. Basicamente, as setas indicam a direção a seguir e as dependên-
cias associadas às atividades, estas mostradas pelas conexões entre elas. Esse uso 
visual permite identificar facilmente as relações de dependência entre as atividades.
Já no Diagrama de Precedência (DP), as atividades são representadas por retângulos, 
e as dependências são representadas por linhas. Essa representação simplifica a visu-
alização das dependências, pois as atividades são apresentadas de forma mais direta.
34
Tempo, riscos e fatores de impacto em projetos
2
Então quando desenvolvemos um diagrama de rede, é possível identificar as atividades 
que possuem dependências e as relações de precedência entre elas, para que, por fim, 
uma ordem lógica seja seguida com plena identificação das dependências críticas e as 
possíveis folgas no cronograma sejam claras, deste modo é simples dar uma atenção 
especial às tarefas que necessitam de prioridade e uma certa folga às tarefas que não 
dependem de tanta assertividade. 
Método do Caminho Crítico: consiste em identificar as atividades que têm maior impacto no 
cronograma geral, ou seja, aquelas que estão no “caminho crítico”. Isso permite que os es-
forços sejam direcionados a essas tarefas para que o cronograma total não seja impactado, 
deste modo, a utilização dessa técnica auxilia em períodos de criticidade a elencar pessoas-
-chave, alterar prioridades e elencar tarefas de forma que, caso exista um possível atraso, 
a reorganização das prioridades fique simples e fácil. Basicamente, esta técnica consiste 
em identificar as tarefas-chave que podem impedir o seguimento do desenvolvimento das 
demais tarefas (Lima, 2009).
Análise de Recursos: é uma técnica complementar, aplicável para todos os casos previa-
mente citados e envolve simplesmente alocar recursos de forma que todo o cronograma 
esteja coberto. Um grande risco pode ser considerado se alguma das etapas do cronograma 
do projeto não estiver coberta, não se pode realizar uma tarefa sem recursos, sejam eles fi-
nanceiros, tempo de mão de obra, ou tempo de uma consultoria externa, para uma conclusão 
de atividade, alguma movimentação ou impacto aconteceu.
Agora que entendemos algumas técnicas utilizadas dentro de nosso cronograma de 
projeto, podemos desenvolvê-lo da melhor forma, e, ao final, utilizar a linha base des-
te cronograma como referência para o controle do tempo do projeto, visto que temos 
incluídas as datas planejadas para as entregas, as sequências lógicas entre elas e a 
duração média para cada atividade.
Figura 01. Cronograma do projeto
35
2
Gestão de projetos tecnológicos
U
ni
ve
rs
id
ad
e 
S
ão
 F
ra
nc
is
co
Fonte: PMI (2014, p. 76). 
1.2 RELAÇÃO COM METODOLOGIAS ÁGEIS E TRADICIONAIS
No geral, metodologias fornecem uma estrutura para orientar os gerentes de projeto 
e suasequipes ao longo de todo o ciclo do desenvolvimento e são complementares a 
um bom cronograma, facilitando no gerenciamento e possibilitando adaptabilidade às 
necessidades de cada projeto. Elas servem como um guia para orientar as melhores 
práticas e abordagens para lidar com os desafios e incertezas inerentes aos projetos 
(Kerzner; Saladis, 2017). 
Acerca do relacionamento entre o tempo e as metodologias, devemos considerar tanto as 
ágeis, quanto as tradicionais. No contexto de projetos de TI, vamos compreender separa-
damente a relação entre elas e este precioso e delicado conceito da gestão de projetos.
Metodologias Ágeis: metodologias como Scrum e Kanban enfatizam ciclos curtos de de-
senvolvimento, normalmente chamados de “sprints”, que variam de uma a quatro semanas 
em média. Este tipo de iteração, permite a entrega contínua de incrementos funcionais do 
sistema, o que proporciona maior visibilidade e feedback rápido dos stakeholders.
Neste caso, associamos esses benefícios com a flexibilidade, graças a capacidade de se 
adaptar às mudanças ao longo do ciclo e permitir a priorização e redefinição contínua dos 
36
Tempo, riscos e fatores de impacto em projetos
2
requisitos com base no feedback das partes interessadas. Este modo de desenvolvimento 
só é possível graças às entregas de valor aos usuários em incrementos menores e mais fre-
quentes, possibilitando um sentimento de agilidade por parte do cliente e ajustes e melhorias 
contínuas ao longo do tempo por parte do time de desenvolvimento.
Metodologias Tradicionais: metodologias em modelos como “cascata” e em “V” tendem 
a enfatizar o planejamento detalhado do projeto pré-desenvolvimento efetivo, isso envolve 
a definição completa dos requisitos, arquitetura e design do sistema logo antes do projeto 
ser iniciado efetivamente. Nesses casos, o desenvolvimento ocorre em fases sequenciais e 
respectivas, o que demanda um maior tempo durante a execução do projeto.
Sobre o quesito mudanças, podemos ter problemas para fazê-las durante a utilização desse 
modelo de desenvolvimento, alterar tópicos em fases anteriores podem exigir retrabalhos e, 
consequentemente, essa alteração acaba ocasionando um atraso no feedback dos stakehol-
ders, o que novamente pode gerar retrabalhos, de forma que o ciclo de desenvolvimento vai 
atrasando seu fluxo normal.
Metodologias ágeis e tradicionais têm suas próprias vantagens e desvantagens em relação à 
gestão do tempo em projetos de TI. A escolha da abordagem mais adequada dependerá das 
necessidades e características específicas do projeto, bem como das preferências e cultura 
organizacional como discutido.
IMPORTANTE
1.3. ESTIMATIVAS DE TEMPO EM SOFTWARE
Como mais um fator crítico para qualquer execução, as estimativas de tempo em proje-
tos de software são fundamentais para um bom planejamento e elaboração do escopo 
de gerenciamento robusto, com elas conseguimos prever da melhor maneira possível 
o tempo necessário para concluir as atividades e entregar ao final uma base para a 
elaboração do cronograma.
Este tema, exposto pelo autor Steve McConnell como “black art” por causa de sua comple-
xidade e incerteza, exige um conhecimento de conceitos e técnicas prévias para se obter 
proficiência em estimativas. Abaixo iremos explorar técnicas e suas aplicações para que a as-
sertividade da estimativa seja um ponto comum em um desenvolvimento (McConnell, 2006).
Estimativa baseada em tamanho funcional: envolve medir o tamanho do software em 
termos de funcionalidades, como pontos de função ou outras métricas, e estabelecer uma re-
lação entre o tamanho e o tempo necessário para desenvolvê-lo. Ela busca estimar o esforço 
e o tempo de desenvolvimento com base na quantidade e complexidade das funcionalidades 
envolvidas, quanto mais tarefas e funções, maior o tempo associado ao desenvolvimento.
Estimativa baseada em tarefas: envolve dividir o trabalho do projeto em tarefas menores e 
estimar o tempo necessário para concluir cada tarefa. É uma técnica mais genérica, em que 
37
2
Gestão de projetos tecnológicos
U
ni
ve
rs
id
ad
e 
S
ão
 F
ra
nc
is
co
as atividades específicas são estimadas individualmente, e somadas ao final, sua aplicação 
acaba sendo demorada, visto que diversas discussões e reuniões de alinhamento são ne-
cessárias para sua elaboração, mas a visão micro de cada ponto pode ajudar em um melhor 
planejamento e identificação de correlação e dependência entre tarefas.
Estimativa baseada em histórico ou Estimativa análoga: utiliza projetos históricos como 
base para sua tomada de decisão, basicamente, utiliza projetos anteriores semelhantes como 
referência para estimar o tempo necessário para o projeto atual. É baseada na premissa de 
que “projetos semelhantes tendem a ter durações semelhantes”, além dos mesmos impactos 
e fatores que podem influenciar em sua duração, sua utilização é comum principalmente em 
empresas com uma boa gama de projetos implantados, visto que a quantidade de dados para 
consulta e análise é grande (PMI, 2021). 
Estimativa paramétrica: utiliza modelos matemáticos e estatísticos para fazer estimativas 
de tempo com base em parâmetros específicos do projeto. Ela envolve o uso de fórmulas, 
equações ou algoritmos que levam em consideração variáveis como tamanho do software, 
complexidade, recursos disponíveis e histórico de desempenho. As durações das atividades 
são quantitativas em alguns casos, calculadas através da multiplicação da quantidade de 
trabalho pelas horas de mão de obra disponíveis para cada tarefa, tendo assim uma visão 
clara de qual a demanda de trabalho (PMI, 2021). 
Estimativa de Três Pontos: também conhecida como técnica PERT (Program Evaluation 
and Review Technique), fornece um aperfeiçoamento da precisão acerca de estimativas de 
duração de atividades pontuais, visto que fornecem uma duração esperada e consideram a 
faixa de incerteza sobre a duração esperada. A partir dessas estimativas, é possível calcular 
uma estimativa ponderada da duração da tarefa (PMI, 2021).
Basicamente, esta consiste em obter três estimativas de cada atividade, nomeadas de tM, tO 
e tP, estas descritas abaixo: 
 ` Mais provável (tM): esta estimativa é calculada considerando a duração da atividade e 
levando em conta os recursos que provavelmente serão alocados, às expectativas realis-
tas de disponibilidade para realizar a atividade, as dependências e possíveis interrupções 
que possam ocorrer durante a execução da atividade.
 ` Otimista (tO): a duração da atividade é determinada com base na análise do cenário ideal 
para a realização da atividade, ou seja, sem imprevistos.
 ` Pessimista (tP): a duração da atividade é determinada com base na análise do cenário 
mais desfavorável para a realização da atividade.
Após estas definições, existem duas maneiras comumente usadas para calcular a duração 
esperada (tE) da tarefa com base nos valores de distribuição assumidos. Essas fórmulas são 
a de distribuições triangular, que tem foco em considerar uma média entre as três situações, 
e a beta, que tem foco em ponderar considerando que o caso médio é quatro vezes mais 
provável de acontecer.
38
Tempo, riscos e fatores de impacto em projetos
2
Figura 02. Fórmulas Pert
tE – Duração Esperada
tO – Otimista 
tM – Mais Provável 
tP – Pessimista 
DISTRIBUIÇÃO TRIANGULAR
tE = (tO + tM + tP) / 3
DISTRIBUIÇÃO BETA
tE = (tO + 4tM + tP) / 6
Fonte: elaborada pelo autor.
Outros: além dos citados, o uso de modelos estatísticos, como regressão linear e análise de 
Monte Carlo, para estimar o tempo em projetos de software são comuns. Estes modelos são 
construídos também com base em dados históricos de projetos anteriores e podem fornecer 
estimativas mais precisas, visto que levam em consideração outros fatores, como variabilida-
de e os riscos associados ao projeto (Jones, 2007).
1.4. MONITORAMENTO E CONTROLE DO TEMPO
Não menos importante que o processo de definição de cronograma ou estimativa do 
tempo, o monitoramento e controle do tempoengloba garantir o cumprimento dos prazos 
estabelecidos em um projeto ou implantação. Essas atividades envolvem o acompanha-
mento do progresso da conclusão das atividades, a comparação dos resultados obtidos e 
a implementação de ações corretivas e tomadas de decisão quando necessário.
O objetivo do monitoramento e controle do tempo é garantir que o projeto esteja seguin-
do o cronograma estabelecido e que as atividades estejam sendo concluídas dentro dos 
prazos previstos. Isso envolve o registro e acompanhamento do tempo gasto em cada 
atividade, a identificação de possíveis atrasos e a implementação de medidas para 
mitigar esses atrasos.
Para tais análises, o uso de “KPI’s” (Indicadores chave de performance) se faz necessá-
rio. O índice de desempenho do cronograma (SPI) é o mais comum neste tipo de aná-
lise de tempo, visto que auxilia no controle de desvios e avanços no quesito progresso.
O SPI é calculado dividindo-se o tempo das atividades concluídas pelo tempo planejado 
para execução destas atividades. Esse índice indica a eficiência com que o projeto está 
sendo executado em relação ao cronograma, um SPI de 0,5, mostra que o projeto está 
eficiente, e que as tarefas estão sendo realizadas com a metade do tempo planejado, já 
um indicador SPI de 1,5 mostra que o projeto está atrasado em cinquenta por cento se 
comparado com o cronograma, o valor 1, mostra que o projeto está cem por cento em 
linha com o cronograma. 
39
2
Gestão de projetos tecnológicos
U
ni
ve
rs
id
ad
e 
S
ão
 F
ra
nc
is
co
É fundamental destacar que o monitoramento e controle do tempo são atividades cons-
tantes ao longo dos projetos e suas realizações geram base para tomadas de decisão 
necessárias ao longo do projeto, uma identificação de desvio logo no início do anda-
mento, possibilita folga para tomada de decisão e auxilia em garantir o sucesso da 
entrega no período previamente definido e acordado.
2. COMO O TEMPO É UM FATOR-CHAVE E PODE SER UM 
DIFERENCIAL
Pudemos perceber até aqui que o tempo desempenha um papel fundamental em projetos 
e que este pode ser um fator determinante para o seu sucesso ou fracasso. Sua gestão 
permite que as atividades sejam concluídas dentro dos prazos estabelecidos, garantindo 
a entrega correta do projeto, além de proporcionar a otimização dos recursos disponíveis, 
poupar gastos e trazer outros benefícios significativos durante o ciclo de execução.
O tempo é um recurso precioso em projetos, e gerenciá-lo com eficiência é essencial para 
alcançar resultados bem-sucedidos (Kerzner; Saladis, 2017).
PARA REFLETIR
Acerca do tópico tempo, podemos aprimorar nossos entendimentos e discutir mais a 
fundo técnicas e conceitos chaves para garantir o diferencial tão necessário nas áreas 
de tecnologia.
2.1. ENTREGA RÁPIDA 
A entrega rápida em Tecnologia da Informação (TI) é um quesito necessário a se dis-
cutir, principalmente devido à relevância da velocidade e agilidade na era digital, novos 
conceitos como o DevOps e o Lean Software são abordagens que se destacam nesse 
contexto, em que o foco é a agilidade e qualidade da entrega final do produto (Forsgren; 
Humble; Kim, 2018).
O DevOps é uma espécie de modelo cultural, seu foco é a utilização de um conjunto de 
práticas que busca integrar as equipes de desenvolvimento (Dev) e operações (Ops) 
para um melhor desenvolvimento do produto, projeto ou tarefa, promovendo um am-
biente colaborativo e de grande eficácia, seu objetivo principal é aumentar a frequência 
de entregas e confiabilidade dos testes, consequentemente melhorando o projeto como 
um todo e a satisfação do cliente. 
Por sua vez, o Lean Software (Software enxuto) é baseado nos princípios do Lean 
Manufacturing (Manufatura Enxuta), com foco em gestão e eliminação de desperdícios. 
Seu foco principal é maximizar o valor entregue aos clientes, entregas diretas e median-
te a necessidade. Em desenvolvimento de software, busca reduzir atividades que não 
agregam valor, como retrabalhos, fluxos desnecessários e tarefas onde a burocracia 
não se faz necessária.
40
Tempo, riscos e fatores de impacto em projetos
2
Ambas as abordagens citadas têm 
sua base em processos de melhoria 
contínua e dentro do nicho de desen-
volvimento de software, reforçam for-
temente a automatização de tarefas, 
principalmente em simulações de QA 
(Garantia da Qualidade) e UX (Ex-
periência do usuário). Essas auto-
mações otimizam fluxos e garantem 
confiabilidade na entrega do produto 
final devido à velocidade e à quanti-
dade dos testes realizados.
Em um projeto de entrega rápida, de-
vemos nos concentrar em alcançar metas globais estabelecidas de maneira ágil, confi-
ável e segura, buscando alto desempenho. Estudos demonstram que as organizações 
capazes de entregar software de forma eficiente têm duas vezes mais chances de supe-
rar as metas em termos de quantidade de produtos ou serviços, eficiência operacional, 
satisfação do cliente, qualidade dos produtos ou serviços, e alcance dos objetivos da 
organização ou missão. Esses resultados destacam a capacidade de entrega veloz de 
um software como uma verdadeira vantagem competitiva para os negócios em desen-
volvimento de sistemas (Forsgren; Humble; Kim, 2018).
2.2. CICLOS DE ITERAÇÃO CURTOS
Os ciclos de iteração curtos são uma abordagem fundamental e complementar acerca 
da entrega rápida de projetos em TI, essa técnica baseia-se em dividir o projeto em 
pequenas tarefas e entregas com incrementos posteriores possíveis, com a função de 
permitir que o valor agregado do projeto seja aumentado, pequenas entregas podem 
proporcionar incrementos parciais, e deste modo o projeto não necessita de um longo 
período de desenvolvimento para que o resultado da entrega seja mensurado.
Essa abordagem traz diversas vantagens, pois permite uma maior flexibilidade e adap-
tabilidade das equipes, além da mitigação de riscos. Sua característica principal fre-
quentemente é associada a metodologias híbridas, pois as equipes podem receber 
feedback dos usuários e stakeholders mais cedo, possibilitando ajustes e melhorias 
contínuas ao longo do projeto e processo de execução.
No entanto, acerca de sua aplicação, é importante ressaltar que a implementação de 
ciclos de iteração curtos requer uma boa gestão do tempo, além da priorização eficiente 
das tarefas e uma abordagem colaborativa entre as equipes principalmente quando fa-
lamos em desenvolvimentos nestes moldes de ciclo com times globais e fusos horários 
diferentes. O gerente de projetos, portanto, se faz um fator indispensável, visto que sua 
coordenação adequada garante que cada ciclo seja entregue no prazo e de acordo com 
o esperado.
Figura 03. Entrega Rápida
Fonte: Freepik. Acesso em: 11 ago. 2023. 
41
2
Gestão de projetos tecnológicos
U
ni
ve
rs
id
ad
e 
S
ão
 F
ra
nc
is
co
Uma outra boa prática nesses ciclos é criar camadas de abstração para separar a implemen-
tação detalhada de um componente ou sistema da sua interface externa, atuando como uma 
camada intermediária que oculta a complexidade interna do componente, fornecendo uma 
interface mais simples e abstrata para os usuários ou outros componentes interagirem.
Por exemplo, em uma aplicação desktop escrita em Visual Basic, no Windows, é comum que 
toda a lógica esteja concentrada em eventos. 
Para criar uma camada de abstração nesse tipo de aplicação, é necessário adaptar a lógica 
para uma estrutura orientada a objetos e refatorar o código existente nos eventos em um 
conjunto de classes Visual Basic (ou possivelmente C#). A nova interface do usuário (por 
exemplo, uma interface para a web) pode então utilizar essa nova lógica. Vale ressaltar que 
não é necessário criar interfaces para a implementação da lógica, a menos que haja a inten-
ção de implementar recursos de ramificação por meio de abstração na lógica.
Há casos em que não se remove a camada de abstração no final, como quando os usuários do 
sistema têm a liberdade de escolher a implementação. Nesse caso, você está essencialmente 
criandouma API de plugins. Ferramentas como OSGi (Sistema Modular e Dinâmico), usadas 
pelo Eclipse, podem facilitar esse processo para equipes que utilizam Java. É melhor não criar 
uma API desse tipo desde o início do projeto. Em vez disso, crie a implementação inicial, em 
seguida, crie uma segunda implementação e extraia uma API a partir dessas implementações. 
À medida que você adiciona novas implementações, perceberá que sua API muda rapidamen-
te. Se a intenção é disponibilizar essa API publicamente para que outros desenvolvam seus 
próprios plugins, é necessário esperar que ela se estabilize antes de divulgá-la.
HUMBLE, Jez; DAVID Farley. Entrega contínua: como entregar um software de forma rápida 
e confiável. Porto Alegre: Bookman, 2014. (Disponível na Minha Biblioteca)
SAIBA MAIS
2.3. GESTÃO DO TEMPO EM PROJETOS GLOBAIS OU DISTRIBUÍDOS
A gestão do tempo em projetos globais ou distribuídos é outro desafio significativo e 
complexo para quaisquer abordagens, metodologias e tipos de projetos, necessitamos 
de uma postura cuidadosa quando na definição do time nos deparamos com este con-
texto, equipes de trabalho localizadas em diferentes fusos horários, regiões e culturas, 
podem ter vícios e costumes diferentes, um ponto crítico que pode dificultar a coorde-
nação eficiente e o cumprimento dos prazos previamente estabelecidos.
Lidar com esta estrutura pode exigir o uso de ferramentas colaborativas e de comunicação 
efetiva, como videoconferências, chats e sistemas de gerenciamento de projetos on-line, ferra-
menta imprescindível para tal caso, visto que ajuda a manter todos os envolvidos informados e 
alinhados com as atividades em andamento. Alguns exemplos de sistemas de gerenciamento 
de projetos on-line populares são o Trello, Asana, Basecamp, Jira e Microsoft Project Online.
Projetos com divisões deste tipo exigem uma abordagem estruturada e eficaz, visto que 
a promoção de uma cultura colaborativa e de confiança entre as equipes faz-se indis-
pensável para a garantia da comunicação eficiente e adoção de práticas com foco em 
minimizar os desafios associados à distância geográfica, garantindo a entrega dentro 
dos prazos estabelecidos (Kerzner; Saladis, 2017).
42
Tempo, riscos e fatores de impacto em projetos
2
2.4. DESAFIOS NA ELABORAÇÃO DE UM CRONOGRAMA
Outro ponto que necessitamos discutir acerca de um cronograma de projeto são os de-
safios que podem ser apresentados em sua elaboração, considerando que na maioria 
dos métodos disponíveis, o gestor, ou empresa mantenedora do projeto, impõe como 
restrito o tempo ou os recursos para a execução, necessitamos, assim, considerar algu-
mas dificuldades comuns na elaboração de um cronograma de projeto.
Um projeto restrito por tempo é aquele que deve ser concluído até uma data específica 
e, se necessário, podem ser alocados recursos adicionais para garantir o cumprimento 
desse prazo. Já um projeto restrito por recursos assume que o nível de recursos dispo-
níveis não pode ser ultrapassado e, se os recursos forem insuficientes, é aceitável atra-
sar o projeto, desde que seja o mínimo possível, para que sejam utilizados os recursos 
disponíveis (Larson; Gray, 2016, p. 217).
Resumindo, em termos de cronograma, a restrição por tempo significa que o tempo de 
duração do projeto é fixo e os recursos podem ser flexíveis, enquanto a restrição por 
recursos implica que os recursos são fixos e o tempo pode ser flexível. Caso tenhamos 
dificuldade para determinar se o projeto é restrito por tempo ou por recursos, pode-
mos realizar um teste simples para ajudar nessa classificação, nos questionar: “Se o 
caminho crítico do projeto atrasar, serão acrescentados recursos para recuperar o cro-
nograma?”. Se a resposta for sim, assume-se que o projeto é restrito por tempo, caso 
contrário, assume-se que é restrito por recursos (Larson; Gray, 2016, p. 217).
3. A IMPORTÂNCIA DA GESTÃO DE UM CICLO DE VIDA EM 
PROJETOS DE TI
Sempre com fatores externos impactando o andamento do projeto, e com atitudes e 
estratégias que otimizam as tarefas em desenvolvimento, quando o assunto é software 
podemos ter à primeira vista a ideia de que este “mundo” funciona de forma diferente 
devido às constantes mudanças, mas, na verdade, não é bem assim. Podemos sim 
generalizar o ciclo de vida em projetos tecnológico, embora cada aplicação e desen-
volvimento tenha um objetivo e resolva um problema diferente, podemos observar um 
padrão, sabemos que todo desenvolvimento passa por fases e que elas têm grande po-
der em determinar o resultado final do ciclo de desenvolvimento (Humble; Farley, 2013). 
3.1. FASES DE UM CICLO DE VIDA 
As fases, em sua maioria, são consideradas como um ciclo sequencial, onde cada fase 
precisa ser concluída antes do início da próxima. No entanto, é importante destacar que 
em projetos ágeis ou iterativos, comuns para a área tecnológica, as fases podem ser 
adaptadas para permitir a entrega em partes, de forma incremental, com o único objeti-
vo de gerar valor ao longo do andamento.
De acordo com o PMBOK (PMI, 2021), podemos agrupar as fases em quatro tópicos, 
planejamento, execução, monitoramento e controle, e encerramento, vale sinalizar que 
temos pontos de destaque em cada uma das fases, estas chamadas de atividades-cha-
ve. Vamos explorar cada uma delas?
43
2
Gestão de projetos tecnológicos
U
ni
ve
rs
id
ad
e 
S
ão
 F
ra
nc
is
co
Planejamento: Fase em que ocorre a definição das metas do projeto, a análise de requisitos, 
a identificação dos stakeholders e a elaboração de um plano detalhado para guiar a execu-
ção do projeto, geralmente é embasado por documentações como EAP e TAP no quesito pla-
nejamento e escopo, além da identificação de riscos, definição de um cronograma e criação 
de um orçamento.
Execução: Fase em que as atividades planejadas no estágio anterior são colocadas em prá-
tica, é o momento onde se aloca a equipe e recursos para realização das tarefas segundo o 
cronograma, neste ponto o GP (Gerente de Projetos) tem o trabalho importante de monitorar 
o progresso, portanto sistematicamente são realizadas reuniões de alinhamento com o time 
(Briefings), para tomada de decisões em conjunto, de modo a garantir que tudo esteja cami-
nhando conforme o planejado (PMI, 2021). 
Quando falamos de software, este momento de execução é o mais delicado, temos pontos 
necessários a considerar para que o desenvolvimento seja efetivo, principalmente em ciclos 
iterativos, segundo Jez Humble e David Farley (2013, p. 452) alguns pontos, devemos tratar 
como base ao longo do ciclo de desenvolvimento iterativo, estes, são os listados abaixo:
 ` É essencial contar com um conjunto abrangente de testes de qualidade, estes que englo-
bam desde testes unitários até testes de componente e de aceitação de ponta a ponta. 
Esses testes devem ser executados a cada checkpoint (Marco) no código, para garantir 
a confiabilidade.
 ` A cada iteração, devemos utilizar um ambiente teste (Ambiente de qualidade) similar ao de 
produção para demonstrá-lo aos usuários, assim obtemos um feedback regular dos clientes 
ou patrocinadores e garantimos que o desenvolvido tem mais chances de ser aceito. 
 ` Devemos priorizar funcionalidades por valor de negócio, visto que o software pode se tornar 
útil muito antes do final do projeto. Existem várias boas razões para disponibilizar o software 
assim que ele possua alguma funcionalidade útil, uma delas é gerar valor na aplicação mes-
mo enquanto ainda está em desenvolvimento.
 ` A manutenção contínua do software é necessária, sempre garantindo seu pleno funciona-
mento, é outro ponto chave, visto que traz disciplina à equipe e evita problemas como longas 
fases de integração e refatorações que causam impactos negativos ao andamento.
Monitoramento e Controle: já nesta fase do projeto, seu avanço é acompanhado de per-
to, principalmente pelo GP, avaliações regulares são feitas para garantir o cumprimento do 
escopo, cronograma e orçamento, além de facilitarem a gestão de eventuais desvios ouproblemas que possam surgir. Para desenvolvimentos de softwares, nesta fase, o foco se dá 
na obtenção do código pronto ao fim de cada iteração, visto que essa é a única medida real 
de progresso neste tipo de projeto (Humble; Farley, 2013).
Encerramento: nesta fase, as atividades relacionadas ao projeto são finalizadas e organi-
zadas como entregáveis de forma clara e simples, desde a entrega dos resultados finais aos 
stakeholders, até toda a documentação associada ao projeto. Ao GP cabe o checklist (Lista 
de verificações) para garantir que realmente tudo foi checado e testado, para que não ocor-
ram deslizes e falhas que possam gerar um retrabalho posterior.
44
Tempo, riscos e fatores de impacto em projetos
2
3.2. ESTRUTURA DO CICLO DE VIDA
Abordando sobre o contexto do ciclo de vida de um projeto, a estrutura é um elemento 
essencial para garantir a eficiência e a qualidade dos processos. Duas abordagens am-
plamente utilizadas na estruturação do ciclo de vida são a V (Verification and Validation) 
e o modelo espiral.
A abordagem V, também conhecida como V-Model, é um modelo sequencial em que são 
relacionadas as atividades de verificação e validação às fases do ciclo de vida do projeto. 
Basicamente, a ideia desse modelo é garantir que as atividades de verificação e validação 
sejam realizadas em paralelo às atividades de desenvolvimento, com o objetivo de a me-
dida que o desenvolvimento efetivo seja feito, pontos de controle sejam implementados 
e por sua vez sigam verificando se o resultado final atende às necessidades do cliente.
Já o modelo espiral retoma a ideia de uma abordagem iterativa e incremental, que com-
bina elementos do modelo cascata com feedback contínuo, é desenvolvido com sua 
base em ciclos de desenvolvimento, nos quais as atividades são divididas em pequenas 
partes e chamadas de iterações. A cada iteração são realizadas análises de risco, de 
andamento do desenvolvimento, e de verificação e validação.
Ambas as abordagens possuem vantagens como as citadas, mas também desafios 
atrelados a sua utilização. O modelo V pode ser inflexível diante de mudanças nos 
requisitos e geralmente exige um planejamento mais detalhado e demorado devido à 
maneira que se desenvolve. Já o modelo espiral necessita de uma equipe experiente 
para sua utilização e um acompanhamento rigoroso das iterações, visto que cada etapa 
necessita de uma série de análises para que a metodologia seja aplicada corretamente. 
Figura 04. Ciclo de vida do projeto
Fo
nt
e:
 1
23
R
F
Projeto
Identificação 
Planejamento 
Desenvolvimento Controle
Implementação
Fechamento
45
2
Gestão de projetos tecnológicos
U
ni
ve
rs
id
ad
e 
S
ão
 F
ra
nc
is
co
Portanto, concluímos que a escolha da estrutura mais adequada dependerá das ca-
racterísticas e necessidades específicas de cada projeto e equipe de desenvolvimento.
3.3. TOMADA DE DECISÃO
Outro tópico crítico e indispensável durante qualquer ciclo de vida é garantir a tomada 
de decisão assertiva, esta desempenha um papel crucial para resultados positivos. Em 
diversos casos podemos aplicar técnicas para que a escolha seja efetiva, e tanto o tem-
po quanto os riscos sejam impactados positivamente.
 ` Avaliação de tecnologias: ao longo do ciclo de vida, podem surgir várias opções tecno-
lógicas para a implementação de soluções. A tomada de decisão nesse contexto envolve 
avaliar as tecnologias disponíveis, a compatibilidade e possíveis impactos dela em diver-
sos quesitos, escalabilidade, segurança, suporte de terceiros e confiabilidade.
 ` Seleção de fornecedores: em muitos projetos de TI, em sua maioria focados para a 
área de implantação de servidores e construção de redes, é necessário adquirir produtos, 
equipamentos ou serviços de fornecedores externos. A tomada de decisão nesse caso 
envolve selecionar os fornecedores adequados, levando em consideração critérios como 
capacidade técnica, experiência, preço, suporte pós-venda e prazo de entrega principal-
mente, este que pode ser um divisor de águas para garantir o sucesso do projeto.
 ` Escolha de metodologia de desenvolvimento: existem diversas metodologias de de-
senvolvimento de software, como cascata, ágil, entre outras já apresentadas no contexto 
do gerenciamento. A tomada de decisão envolve selecionar a metodologia mais adequada 
para o projeto, considerando fatores como requisitos do cliente, complexidade do projeto, 
prazos, recursos disponíveis e cultura organizacional.
 ` Avaliação de riscos e medidas de segurança: a segurança da informação e a gestão de 
riscos são tópicos-chave para qualquer projeto de TI, a tomada de decisão nesse contexto 
envolve identificar os riscos associados ao projeto, avaliar sua probabilidade e impacto 
associado a diversos temas desde segurança até o tempo.
 ` Priorização de requisitos: em projetos tecnológicos, é comum que tenhamos uma lista 
extensa de requisitos, e recursos limitados para atendê-los, o ciclo de trabalho de um de-
senvolvedor é cheio de desafios. A tomada de decisão, nesse contexto, envolve priorizar 
os requisitos com base no impacto para o avanço e valor agregado da tarefa.
Com base no que vimos, a tomada de decisão é um ponto delicado que impacta o pro-
jeto em diversos fatores. A decisão adequada pode resultar no sucesso do projeto, ou 
ao menos assegurar que a tarefa específica seja bem-sucedida, quanto mais assertiva 
a decisão, menor o impacto e o risco associado.
PARA REFLETIR
Tomada de decisão assertiva é a chave para o sucesso em projetos, pois cada escolha in-
fluencia diretamente o curso e os resultados finais do projeto (Wysocki, 2013).
46
Tempo, riscos e fatores de impacto em projetos
2
3.4. CONTROLE E MONITORAMENTO DO PROGRESSO
O controle e o monitoramento do progresso de um projeto são fundamentais para ga-
rantir que ele esteja em conformidade com o cronograma e o orçamento estabelecido. 
Para que esta análise seja possível, é necessário ter uma estrutura de sistema de infor-
mação de monitoramento de projetos que define quais dados serão coletados, como, 
quando e por quem serão coletados, além da análise e relatório do progresso atual.
Os dados são determinados pelas métricas utilizadas para o controle do projeto e, em 
sua maioria, são coletados diariamente e sem interrupções que possam mascarar os 
resultados, o uso de recursos até o momento referência da avaliação são comparados 
com os tempos de trabalho, estimativas e orçamentos planejados até o momento. Esta 
comparação faz-se essencial, pois fornece ao gerente e às partes interessadas, dados 
que respondem a perguntas comuns como, “qual o status atual do projeto em termos 
de cronograma e custo?” e “quais os problemas potenciais para exceder o budget (or-
çamento), ou atrasar o cronograma?”
Seguindo o fluxo após definir os dados a serem coletados, deve-se estabelecer como 
adquiri-los, nesta etapa, podemos questionar e consultar pessoas chave associadas às 
tarefas e marcos, dentre elas as equipes do projeto e terceiros, ou até mesmo aces-
sá-los eletronicamente em controles, bases, e-mails ou sistemas. Estes processos de 
coleta e análise de dados permitem que o gerente do projeto tenha informações preci-
sas sobre o andamento, possibilitando a tomada de decisões, identificação de desvios, 
antecipação de problemas, e pontos-chave para a mitigação dos riscos.
4. ANÁLISE DOS RISCOS DE PROJETOS TECNOLÓGICOS
Não menos importante, a análise dos riscos em projetos tecnológicos é essencial para 
identificar e avaliar potenciais fatores que podem impactar negativamente e positiva-
mente o sucesso do projeto. Essa análise envolve a identificação dos riscos, a análise 
de sua probabilidade de ocorrência e impacto, além da definição de estratégias de 
mitigação (para o caso negativo). O PMBOK define riscos como eventos futuros e de 
ocorrência incerta que podem afetar o andamento e objetivos do projeto (Lima, 2009).
O gerenciamento eficaz de riscos em projetos de tecnologia da informação é fundamental para 
reconhecer e reduzir as possíveisameaças que poderiam prejudicar o êxito do projeto, asse-
gurando, assim, a entrega de soluções tecnológicas seguras e confiáveis. (Schwalbe, 2015).
PARA REFLETIR
Neste tópico, exploraremos uma série de etapas para uma análise efetiva dos riscos 
(com foco nos negativos), desde as etapas de identificação, avaliação de probabilidade 
e impacto até as etapas de mitigação deles.
47
2
Gestão de projetos tecnológicos
U
ni
ve
rs
id
ad
e 
S
ão
 F
ra
nc
is
co
4.1. IDENTIFICAÇÃO INICIAL DOS RISCOS
O primeiro passo quando o assunto é risco, é identificar todos os possíveis impactos 
que eles podem causar sobre o projeto, como falhas na implantação de hardware para 
um servidor devido à falta de um componente, ou atraso na entrega de um software, 
devido a mudanças nos requisitos, problemas de segurança, entre outros. 
Uma maneira eficaz de identificar riscos é conduzir workshops ou reuniões com a equi-
pe do projeto. Do mesmo modo que se faz em uma análise de requisitos, outra prática 
necessária nesta fase é retornar as documentações iniciais como TAP e EAP e observar 
os riscos incluídos nesta etapa, para aí seguir com uma análise mais robusta.
Outra maneira de identificação de riscos comum para projetos é o uso da análise SWOT. 
Essa técnica examina o projeto do ponto de vista de suas forças e fraquezas, oportunidades 
e ameaças (SWOT), seu foco é aumentar a abrangência dos riscos identificados, incluindo 
os riscos gerados internamente. Seu uso é simples, começa com a identificação das forças 
(S - strenghts) e fraquezas (W - weakenesses) da organização, enfatizando a organização 
do projeto, ou a área de negócio em geral, em seguida, se segue identificando as oportu-
nidades (O - opportunities) do projeto resultantes das forças da organização, assim como 
as ameaças (T - threats) relacionadas com as fraquezas. Essa análise também destaca a 
compensação das forças para superar as fraquezas (PMI, 2014, p. 122). 
Figura 05. Análise SWOT
Forças
STRENGHTS WEAKENESSES OPPORTUNITIES THREATS
Fraquezas Oportunidades Ameaças
S W O T
Fonte: Freepik.com. Acesso em: 11 ago. 2023. 
4.2. AVALIAÇÃO DE RISCOS
Após uma identificação inicial, podemos seguir com uma avaliação de causas e do 
efeito dos itens levantados. Para a elaboração de um plano de contingência, no quesito 
causa, geralmente observamos fatores do projeto que nos levam a esta questão, no 
48
Tempo, riscos e fatores de impacto em projetos
2
momento em que se realiza o levantamento do risco a causa que leva a ele é mapeada. 
Acerca do efeito este pode impactar sobre mais de uma área do projeto (Ex: crono-
grama, orçamento e qualidade), cabe então a classificação da área de efeito primário 
e secundário, respectivamente, aquele que sofre o impacto direto e as demais áreas 
impactadas (Gambini, 2016).
Para tais levantamentos, podemos utilizar técnicas que contribuem para esta análise, 
observe algumas listadas no quadro abaixo:
Quadro 01. Lista de técnicas para análise de risco
TÉCNICA DESCRIÇÃO
Diagrama de Ishikawa Também conhecido como Diagrama de Causa e Efeito ou Diagrama de Es-
pinha de Peixe, é estruturado em forma de espinha de peixe, em que o 
problema ou evento indesejado é colocado no centro e as causas são iden-
tificadas nos “espinhos” que se ramificam a partir dele. Essa técnica ajuda a 
identificar os principais fatores que contribuem para um risco.
Diagrama de Causalidade Semelhante ao Diagrama de Ishikawa, mas foca na relação de causa e 
efeito entre os fatores identificados, em sua elaboração, começa-se identi-
ficando o problema ou evento a ser analisado. Em seguida, são estabeleci-
das as principais categorias de causas relacionadas a esse problema e são 
determinadas as relações analisando como uma causa pode levar a outra, 
traçando os caminhos de influência e dependência.
Mapa Mental Técnica de representação gráfica que ajuda a organizar informações de for-
ma visual e hierárquica, no estilo de um fluxograma sequencial. Permite o uso 
de diferentes estruturas para que a organização fique clara a toda a equipe.
Fonte: elaborado pelo autor. 
Com base na análise dos riscos discutidos, é possível desenvolver estratégias adequa-
das para lidar com as ações preventivamente a sua ocorrência, ou seja, se planejar por 
meio da elaboração de um plano de contingência de riscos ou mesmo alterar pontos 
durante o ciclo de desenvolvimento para evitar a falha e o atraso do cronograma.
4.3 CLASSIFICAÇÃO DOS RISCOS
Após uma análise clara e robusta dos riscos, é importante realizar uma classificação 
da probabilidade de ocorrência de cada risco, e seu impacto no projeto. Para que pos-
samos priorizar os riscos mais significativos e direcionar esforços para sua mitigação, 
uma técnica bastante conhecida é a “Matriz Probabilidade x Impacto”, em que listamos 
os riscos depois de identificados e realizamos uma análise qualitativa, pontuando a 
relevância de cada risco e determinando sua probabilidade, para organizarmos e de-
terminarmos o quão importante é mitigar o risco em questão (Gambini, 2016, p. 171).
A análise se dá pelas classificações de cada tópico de risco, classificando-os como 
“Ameaças” e “Oportunidades” e posteriormente realizando a pontuação multiplicando o 
resultado da sua relevância, de acordo com a decisão da equipe, no quesito “Probabi-
lidade x Impacto”.
49
2
Gestão de projetos tecnológicos
U
ni
ve
rs
id
ad
e 
S
ão
 F
ra
nc
is
co
Quadro 02. Matriz PxI
MATRIZ PROBABILIDADE X IMPACTO (PXI)
Probabilidade Ameaças Oportunidades
Muito 
Alta 5 5 10 15 20 25 25 20 15 10 5
Alta 4 4 8 12 16 20 20 16 12 8 4
Médio 3 3 6 9 12 15 15 12 9 6 3
Baixa 2 2 4 6 8 10 10 8 6 4 2
Muito 
Baixa 1 1 2 3 4 5 5 4 3 2 1
1 2 3 4 5 5 4 3 2 1
Muito 
Baixo Baixo Médio Alta Muito 
Alta
Muito 
Alta Alta Médio Baixo Muito 
Baixo
Impacto
Fonte: elaborada pelo autor.
Ao avaliar a probabilidade de um risco, considera-se apenas a chance de o evento 
ocorrer, independentemente da dificuldade da resolução, a concentração da análise se 
dá unicamente na probabilidade de o risco se concretizar, sem levar em conta outros 
aspectos. Já quando se trata da avaliação do impacto, o foco é exclusivamente no ta-
manho do problema, sem considerar a probabilidade de ocorrência, portanto, a análise 
se concentra na escala das consequências caso o risco efetivamente ocorra, sem levar 
em consideração outros fatores. 
Em resumo:
Avaliação da 
probabilidade
Atenção na 
ocorrência do risco
Atenção nas 
consequências do 
risco
Avaliação do 
impacto
50
Tempo, riscos e fatores de impacto em projetos
2
SAIBA MAIS
No quesito da análise prática PxI (Probabilidade x Impacto), devemos considerar que:
 ` A votação é determinada pela maioria. 
 ` Os especialistas têm voz determinante para a análise e explanação do tema.
 ` A pessoa que vivenciou o cenário mais parecido tem voz para explanação do tema.
(Gambini, 2016).
IMPORTANTE
4.4. PLANO DE CONTINGÊNCIA PARA RISCOS
Após a definição de riscos e já com as devidas classificações em mãos, a equipe deve 
desenvolver o plano de mitigação ou ação para os riscos identificados. A mitigação se 
dá para os riscos negativos (ameaças), e o plano de ação se dá para os pontos positi-
vos (oportunidades). 
Para as ameaças, devemos considerar algumas estratégias de resposta ao risco, defi-
nindo como prevenir, mitigar e aceitar. Cada uma delas envolve uma decisão de como 
lidar com cada situação. Para a prevenção, a equipe do projeto toma ações para eli-
minar completamente a ameaça, esta decisão pode envolver a alteração de requisitos, 
estender o cronograma, reduzir o escopo ou em casos extremos, a suspensão total do 
projeto pode ser considerada. No caso da mitigação, essa estratégia envolve reduzir 
o impacto da possível ocorrência, exemplos de ações de mitigação incluem simplificar 
processos, ou mesmo realizar testes adicionais. Já no caso do aceitar, essa estratégia 
envolve reconhecer a existência do risco e decidir não tomar nenhuma ação a menos 
que o risco ocorra. Aaceitação pode ser passiva, em que não são tomadas ações além 
de documentar a estratégia, ou ativa, em que são estabelecidas reservas para contin-
gências para lidar com os riscos quando ocorrerem (PMI, 2014).
Dentro de projetos, também é possível escolher transferir o impacto das ameaças para ter-
ceiros, junto com a obrigação de lidar com sua resposta. Isso implica em delegar a responsa-
bilidade do gerenciamento de riscos para outra entidade, entretanto, o próprio risco não é eli-
minado. A transferência de riscos pode requerer o pagamento de uma taxa à parte que aceita 
assumir o risco. Exemplos de abordagens de transferência incluem a utilização de seguros, 
acordos contratuais para repassar a responsabilidade de riscos específicos (PMI, 2014).
Já para oportunidades, devemos focar em garantir que elas se concretizem, pois o foco 
em riscos é eliminar toda e qualquer incerteza associada. Assim, podemos seguir com 
a alocação de recursos, direcionamento do foco da equipe para a tarefa, contratando 
mão de obra terceirizada especializada ou realizando mudanças de estratégias com o 
objetivo de identificar e potencializar os principais quesitos dessas oportunidades, forta-
51
2
Gestão de projetos tecnológicos
U
ni
ve
rs
id
ad
e 
S
ão
 F
ra
nc
is
co
lecendo seu benefício e criando condições favoráveis para aumentar sua probabilidade 
de ocorrência (Lima, 2009, p. 181).
5. QUAL A CORRELAÇÃO ENTRE TEMPO E RISCO DOS 
PROJETOS TECNOLÓGICOS
Tempo e risco à primeira vista são conceitos sem similaridade e nenhuma correlação, 
é complicado imaginar como duas métricas com características tão diferentes possam 
estar relacionadas. Em um projeto tecnológico, o tempo refere-se à duração necessária 
para concluir uma fase, atividade ou meta. O risco, por sua vez, representa a probabili-
dade de ocorrerem eventos que possam impactar o andamento do projeto.
Uma correlação entre tempo e risco surge devido a vários fatores, principalmente de-
vido à incerteza associada aos impactos dos eventos no quesito duração da atividade, 
quanto mais riscos associados, mais incerta fica a análise para a elaboração do crono-
grama, e mais complexo fica garantir que o fluxo siga inalterado. O desafio desse tema 
está em encontrar um equilíbrio entre o tempo necessário para concluir o projeto e os 
riscos associados a ele. Técnicas como o planejamento adequado e estratégias de ges-
tão de mudança são essenciais para garantir a assertividade nesse quesito.
5.1. GESTÃO DE MUDANÇAS E IMPACTO NO TEMPO
O tema mudanças é um fator crítico que influencia diretamente o tempo e os riscos do 
projeto ou atividade, quando ocorrem, tendem a afetar significativamente o cronograma 
planejado, resultando em possíveis atrasos, além de impactar diretamente os fluxos e 
demais áreas relacionadas ao projeto, portanto, faz-se necessário revisar e ajustar o 
plano de trabalho e o cronograma. Isso pode envolver a realocação de recursos, re-
definição de prazos, reavaliação de tarefas e até mesmo a revisão das estimativas de 
tempo para se concluir cada etapa.
Uma falta de gestão eficaz das mudanças, pode resultar em falta de eficiência e conse-
quentemente um retrabalho das tarefas associado ao adiamento de demais atividades e 
interrupção do fluxo de trabalho planejado. Mudanças não gerenciadas contribuem para 
prejudicar a confiabilidade, introduzindo novos riscos. A falta de conhecimento técnico, 
problemas de integração ou dificuldades na implementação, por exemplo, são possíveis 
dificuldades que encontramos quando alteramos o escopo incluindo uma nova tecnolo-
gia no ciclo de desenvolvimento. 
Para mitigar os impactos, o uso de estratégias envolve a comunicação efetiva, o en-
volvimento das partes interessadas, a capacitação e treinamento, e o monitoramento 
contínuo das tarefas. Essas estratégias visam minimizar a resistência, obter o apoio das 
pessoas envolvidas, e garantir uma transição suave durante as mudanças, consequen-
temente mitigando riscos. 
5.2. GOVERNANÇA DE TI
O uso da governança em projetos de TI é uma outra boa prática nesse contexto. Consiste 
em utilizar um conjunto de conceitos e processos que visam assegurar a execução eficaz 
52
Tempo, riscos e fatores de impacto em projetos
2
dos projetos, alinhando-os aos objetivos estratégicos da organização. Isso envolve esta-
belecer responsabilidades claras, processos de tomada de decisão estruturados, meca-
nismos de controle adequados e sistemas de monitoramento. A governança em sistemas 
de informação busca garantir que os projetos sejam gerenciados de forma eficiente, com 
transparência, prestação de contas e aderência às melhores práticas, visando obter resul-
tados bem-sucedidos sempre agregando valor ao negócio (Henderikx; Untersteller, 2018).
Várias técnicas de governança em TI podem ser aplicadas para promover a eficácia e o 
alinhamento do desenvolvimento com os objetivos da organização. A seguir, apresenta-
mos algumas técnicas e estratégias para tais controles:
 ` COBIT (Control Objectives for Information and Related Technologies): framework que 
define processos de governança, gerenciamento e controle de TI. Fornece uma estrutura 
abrangente para alinhar os objetivos de negócio com os objetivos, abordando áreas como 
governança corporativa, gerenciamento de riscos, gerenciamento de projetos e gerencia-
mento de serviços. O COBIT define objetivos de controle e métricas-chave para garantir a 
eficiência operacional, a conformidade regulatória e a minimização de riscos (Batista, 2013).
 ` ITIL (Information Technology Infrastructure Library): conjunto de melhores práticas 
para a gestão de serviços de TI. Ele abrange um conjunto de processos e procedimentos 
que abordam a entrega de serviços de TI de qualidade, incluindo o gerenciamento de 
incidentes, problemas, mudanças, configuração, liberação e outros aspectos essenciais. 
O ITIL enfatiza a melhoria contínua e o alinhamento dos serviços, com as necessidades 
do negócio (Batista, 2013).
 ` PRINCE2 (Projects in Controlled Environments): metodologia de gerenciamento de 
projetos amplamente adotada. Define uma abordagem estruturada para o gerenciamento 
de projetos, com ênfase na definição clara de papéis e responsabilidades, controle de 
progresso, gerenciamento de riscos e qualidade. O PRINCE2 fornece orientação para a 
governança efetiva dos projetos de TI, garantindo a entrega dentro do prazo, orçamento 
e escopo definidos.
 ` Balanced Scorecard: técnica que permite traduzir a estratégia organizacional em obje-
tivos mensuráveis. Ele utiliza um conjunto de indicadores financeiros e não financeiros 
para monitorar o desempenho dos projetos em relação aos objetivos estratégicos. Os 
indicadores são agrupados em quatro perspectivas: financeira, cliente, processos internos 
e aprendizado, e crescimento. O Balanced Scorecard ajuda a garantir a criação de valor 
para o negócio e a gestão eficaz em TI.
Figura 06. Governança em TI
Fo
nt
e:
 1
23
R
F
53
2
Gestão de projetos tecnológicos
U
ni
ve
rs
id
ad
e 
S
ão
 F
ra
nc
is
co
As técnicas e estratégias apresentadas proporcionam uma base sólida para a gover-
nança efetiva dos projetos de tecnologia, pois a escolha e a aplicação dependem das 
necessidades e da cultura da organização, bem como dos requisitos específicos de 
cada projeto tecnológico. É importante adaptar as técnicas às circunstâncias e garantir 
uma abordagem holística e integrada para a governança do desenvolvimento.
CONCLUSÃO
Com tudo que estudamos até aqui, pudemos compreender fatores-chave acerca do 
tempo e dos riscos no desenvolvimento de aplicações e implantações tecnológicas, 
abordamos a fundo a importância de uma postura ágil e incremental no desenvolvi-
mento de aplicações e implantações tecnológicas, devido à necessidade de adaptação 
às mudanças, assim, o gerenciamento é facilitado e há a contribuição para um melhor 
controle do tempo e obtenção de feedback dos usuários de forma mais rápida.
Em relação ao tempo, compreendemos que é fundamental estabelecerum cronograma 
realista e bem planejado, considerando todas as etapas do projeto, desde a concep-
ção até a entrega final. Além disso, absorvemos a ideia do monitoramento contínuo do 
progresso do projeto e compreendemos como é essencial identificar desvios e realizar 
ajustes quando necessário, visando garantir que o prazo seja cumprido.
No que diz respeito aos riscos, entendemos que é necessário realizar uma análise 
detalhada dos possíveis eventos adversos que podem afetar o projeto, como atrasos, 
falhas de comunicação, mudanças nos requisitos, entre outros. Observamos conceitos 
de identificação, e avaliação dos riscos, além da importância de manter um plano de 
contingência para lidar com impactos ao longo do desenvolvimento.
Em resumo, compreendemos que um planejamento adequado e monitoramento con-
tínuo do progresso, além de uma gestão ativa dos riscos, são pontos essenciais e di-
ferenciais que, associados, resultam em impactos positivos para a organização e o 
time de desenvolvimento, culminando para uma entrega bem-sucedida e atingindo as 
expectativas dos stakeholders.
54
Tempo, riscos e fatores de impacto em projetos
2
REFERÊNCIAS BIBLIOGRÁFICAS
BATISTA, E. O. Sistemas de informação: o uso consciente da tecnologia para o gerenciamento. 2. ed. Re-
cife: Editora Saraiva, 2013.
FORSGREN, N.; HUMBLE, J.; KIM, G. Accelerate: The Science of Lean Software and DevOps: Building and 
Scaling High Performing Technology Organizations. [S. l.]: IT Revolution, 2018.
GAMBINI, M. Campo Minado em Projetos. [S.l.]: Editora Alta Books, 2016.
HUMBLE, J.; FARLEY, D. Entrega contínua. 1. ed. São Paulo: Grupo A, 2013.
HENDERIKX, M.; UNTERSTELLER, T. Governance in IT Project Portfolio Management: Literature Review 
and Implications for Design Science Research. In: INTERNATIONAL CONFERENCE ON DESIGN SCIENCE 
RESEARCH IN INFORMATION SYSTEMS, 2018, [S.l.]. Anais [...]. Springer, 2018. p. 84-99.
JONES, C. Estimating Software Costs: Bringing Realism to Estimating. Ucrânia: McGraw Hill LLC, 2007.
KERZNER, H.; SALADIS, F. P. Project Management: A Systems Approach. [S. l.]: [s. n.], 2017.
LIMA, G. P. Gestão de projetos: como estruturar logicamente as ações futuras. Rio de Janeiro: LTC, 2009.
LARSON, E. W.; GRAY, C. F. Gerenciamento de projetos. 6. ed. São Paulo: Grupo A, 2016.
McCONNELL, Steve. Software Estimation: Demystifying the Black Art. 1st ed. Redmond, WA: Microsoft Press, 
2006.
PROJECT MANAGEMENT INSTITUTE (PMI). A Guide to the Project Management Body of Knowledge 
(PMBOK® Guide). 7. ed. Newtown Square: Project Management Institute, 2021.
PROJECT MANAGEMENT INSTITUTE (PMI). Um guia de conhecimento em gerenciamento de projetos 
(guia PMBOK®). São Paulo: Editora Saraiva, 2014.
SCHWALBE, K. Information Technology Project Management. 8. ed. Boston: Cengage Learning, 2015.
WYSOCKI, R. K. Effective Project Management: Traditional, Agile, Extreme. Indianapolis: John Wiley & 
Sons, 2013.
55
2
Gestão de projetos tecnológicos
U
ni
ve
rs
id
ad
e 
S
ão
 F
ra
nc
is
co
	_heading=h.gjdgxs