Trabalho Grupo PLM 07-09

7/24/2019 Trabalho Grupo PLM 07-09

1/22

CSE-331-4Simulao eGesto de


2/22

[ 2 ]

CSE-331-4 Simulao e Gesto de

Processos

Trabalho Grupo P!

Eri"ue Si"ueiraEduardo Garte#$raut

%o&'rio (bdala Giacometti


3/22

[ 3 ]

S)!!(%*

Modelo de gesto de projeto para um CUB SAT 5

Capitulo 1 - Introduo 61. 6

1.1 Introduo 61.2 Desenvolvimento do trabalho 6

Capitulo 2 Reviso da Literatura 7

2.1 Iniciaao 72.2 Gerenciamnto do Escopo 7

2.3 Gerenciamento do Tempo 7

2.4 Gerenciamnto do Custo 7

2.5 Gerenciamento do Risco 7

2.6 Necessidade e Requisitos de Stakeholders 8

Capitulo 3 Gesto do Projeto de um CUBSAT 9

3. 9

3.1 Projetos de CUBSATs 9

3.2 Gesto de um projeto de um CUBSAT 93.2.1 Papel do gerente de projetos 9

3.2.2 Gesto do projeto de um CUBSAT 93.2.3 Iniciao 103.2.4 Planejamento 10

3.2.5 Necessidades e Requisitos de Stakeholders 12

3.2.6 Fase de engenharia de sistemas 12

Bibliografia 14


4/22

[ 4 ]


5/22

[ + ]

Modelo de gesto de projetopara um CUB SA


6/22

[ , ]

Capitulo 1 - !"troduo

Resumo:O objetivo deste trabalho desenvolver um modelo para gesto de projeto de um Cubsata alinhado com a viso

transdisciplinar e inovadora de processos, denominada Cincia e Tecnologia Transdisciplinares de Processos (CT2P),

para a criao e anlise de modelos visando a melhoria da gesto dos processos da fase de design do ciclo de vida de

sistemas em misses espaciais.

Keywords: CUB SAT, projeto, escopo, prazo, custo, risco, gerenciamento.

11 .#troduo

A funo de um gerente de projetos planejar, controlar e executar projetos que podem ser pontuais, com uma data para

comear e acabar, ou que podem ser a longo prazo, como o objetivo de negcio de uma empresa.

Este profissional, durante a execuo de um projeto, define papis, atribui tarefas, acompanha e documenta o andamento

da sua equipe atravs de ferramentas e tcnicas apuradas, administra investimentos e integra as pessoas para trabalharem

juntas por um sobjetivo. Tambm funo dele monitorar possveis riscos e estar sempre preparado para mudar de

estratgia rapidamente, se necessrio.

Sem um bom gerente, um projeto acontece de maneira desordenada e com baixa probabilidade de acerto. Um projeto

sem foco e integrao no aproveita o talento dos colaboradores da melhor maneira, demora mais para alcanar seu

objetivo e pode causar um investimento maior que o necessrio.

12 /ese#0ol0ime#to do trabalho

A CTP (Kienbaum, 2014) visa integrao e unificao de vrias disciplinas autnomas (Engenharia de Sistemas,

Gerncia de Projetos, Gesto de Processos de Negcios e Modelagem e Simulaao) que lidam com processos complexos

com diferentes vises, para aplicao em Engenharia Simultnea de Sistemas, sendo esta, por sua vez, definida como o

estudo integrado de processos de engenharia e gesto de sistemas cobrindo todo o ciclo de vida da organizao.

O objetivo deste trabalho desenvolver um modelo de gesto de projetos que possa contribuir com a CTP e apoiar no

planejamento do projeto de um CUBSAT.

Este trabalho estdividido da seguinte maneira:

Capitulo 1:

Capitulo 2:

Capitulo 3:


7/22

[ ]

Capitulo # $ %e&iso da'iteratura

13 .#iciaoO processo de iniciao marca o nascimento do projetoe termina com a autorizao formal para a sua execuo.

Os processos de iniciao normalmente so realizados fora do escopo de controle do projeto, o que pode tornar os limitesdo projeto menos evidentes (Oliveira, 2007).

ara !eldman (200"), O processo de iniciao # o primeiro de uma s#rie de processos da vida do projeto. $%fizemos a per&unta inicial' sso # um projeto*+ ortanto, esse processo serve como ponto de partida oficial que d% incioao projeto.

!eldman (200"), ainda conclui que o processo de iniciao recon-ece que o projeto deve comear ou que oprximo processo de um projeto, j% em andamento, deve comear. or exemplo, antes de passarmos do planejamento /execuo, reavaliaremos o processo de iniciao para determinar se essa transferncia deve realmente acontecer.

1e&undo o PMBOK (2014),o &rupo de processos de iniciao consiste dos processos realizados para definir umnovo projeto ou uma nova fase de um projeto otendo autorizao para iniciar o projeto ou a fase. 3os processos deiniciao, o escopo inicial # definido e os recursos financeiros iniciais so comprometidos. 4s partes interessadas internase externas que vo intera&ir e influenciar o resultado &eral projeto so identificadas. 1e ainda no foi desi&nado, o&erente do projeto ser% selecionado. 5stas informa6es so capturadas no termo de aertura do projeto e no re&istro das

partes interessadas. uando o termo de aertura # aprovado, o projeto # oficialmente autorizado. 5mora a equipe de&erenciamento do projeto possa ajudar a redi&ir o termo de aertura do projeto, este padro pressup6e que a avaliao,aprovao e o financiamento do caso de ne&cio so externos aos limites do projeto (8i&ura 9:;). O limite de um projeto# definido como o momento determinado em que o incio ou a concluso do projeto ou da fase do projeto # autorizado. Oojetivo principal deste &rupo de processos # alin-ar as expectativas das partes interessadas com o ojetivo do projeto,dar:l-es visiilidade sore o escopo e ojetivos, e mostrar como a sua participao nos projetos e em suas respectivasfases pode asse&urar a realizao das suas expectativas. 5stes processos ajudam a estaelecer a viso do projeto, o que

precisa ser alcanado.

1e&undo o PMBOK (2014), os projetos muito &randes e complexos devem ser divididos em fases separadas.

3esses projetos, os processos de iniciao so realizados durante fases susequentes para validar as decis6es tomadasdurante os processos ori&inais de desenvolvimento do termo de aertura do projeto e de identificao das partesinteressadas. 4 execuo dos processos de iniciao no incio de cada fase ajuda a manter o foco do projeto na


8/22

[ ]

necessidade da empresa para o qual o mesmo foi criado. Os crit#rios para o sucesso so verificados e a influncia, osacionadoresm processo deavaliao de alternativas pode ser utilizado para determinar a viailidade do novo empreendimento. odem serdesenvolvidas descri6es claras dos ojetivos do projeto, incluindo as raz6es porque um projeto especfico # a mel-oralternativa para cumprir os requisitos. 4 documentao para esta deciso tam#m pode conter a declarao inicial doescopo do projeto, entre&as, durao do projeto e uma previso dos recursos para a an%lise do investimento da

or&anizao. ?omo parte dos processos de iniciao, o &erente do projeto recee a autoridade para aplicar os recursosor&anizacionais /s atividades susequentes do projeto.

14 Gere#ciame#to do Escopo

Martinelli (2009), a definio do escopo, independente da natureza do projeto, um dos pontos mais importantesna fase inicial do projeto. atravs do escopo que todos os envolvidos tem a fotografia das atividades que serodesenvolvidas para alcanar um determinado objetivo.

Martinelli (2009), continua afirmando que o escopo define as atividades que so necessrias e quando elas devemacontecer ao longo do projeto, de forma que a integrao das atividades propicie atingir um objetivo em um determinado

perodo de tempo.

Segundo Xavier (2006) o planejamento do escopo , portanto, o processo de elaborar e documentar a estratgiapara o desenvolvimento do trabalho (escopo) que irgerar o produto do projeto.

Xavier (2006), o sucesso do projeto estatrelado definio e o gerenciamento do escopo do projeto.

Xavier (2006) , cada projeto exige um balanceamento cuidadoso de ferramentas, fontes de dados, metodologias,

processos e procedimentos, e de outros fatores, para garantir que o esforo gasto nas atividades de determinao doescopo esteja de acordo com o tamanho, complexidade e importncia do projeto.

Xavier (2006), durante o processo de planejamento do escopo do projeto, fundamental que comecemos peladefinio do escopo do cliente, ou seja, que os produtos e servios, relacionados aos objetivos do projeto, sero entreguesa ele.

Segundo o PMBoK (2014), o gerenciamento do escopo do projeto inclui os processos necessrios para assegurarque o projeto inclui todo o trabalho necessrio, e apenas o necessrio, para terminar o projeto com sucesso. Ogerenciamento do escopo do projeto estrelacionado principalmente com a definio e controle do que este do que noestincluso no projeto.

PMBoK (2014), a definio do escopo se se&ue ao entendimento dos ojetivos do projeto, dos resultadosesperados e / descrio sum%ria do traal-o a ser realizado.


9/22

[ ]

PMBoK (2014), @ feita na etapa de iniciao do projeto e detal-ada na etapa de planejamento. Aescreve ascaractersticas do produto e o traal-o necess%rio para realiz%:lo.

PMBoK (2014), O consenso inicial sore o escopo do projeto # estaelecido entre pessoas, or&aniza6es oudepartamentos de or&aniza6es, sendo uma pessoa, empresa, o cliente, o demandante do servio, o prestador de serviosdesi&nado ou outra pessoa, para faz:lo.

PMBoK (2014), emora parea tratar de informa6es redundantes, # um processo necess%rio para explicitar apercepo do que o cliente espera do produto e o que o prestador de servios precisa projetar, produzir, entre&ar.

PMBoK (2014), neste momento, todos os fatores, especialmente prazos e custos, ficam expostos, para no deixar

mar&em a interpreta6es am&uas, emora normalmente seja necess%rio mais adiante rev:los para ajustes dasexpectativas sore o produto.

PMBoK (2014), estes fatores so ne&ociados antes do incio do projeto e explicitados no Bermo de 4ertura dorojeto (roject c-arter),documento que recon-ece formalmente a criao do projeto e pode ter a forma de um acordoformal ou contrato comercial.

PMBoK (2014), adefinio de escopo ajuda a evitar que as equipes de projeto percam tempo e recursos

resolvendo prolemas que fo&em da sua alada.

PMBoK (2014), ainsero, no contrato ou em plano de traal-o elaorado depois do contrato, de cl%usulas soreCo que o projeto no coreC, deixa claro todos os produtos realizados pelo projeto e evidencia as mudanas de escopo.

1e&undo Davier (200E) 4 verificao do escopo # o processo de oteno da aprovao formal desseinstrumento por parte dos envolvidos (staFe-olders) respons%veis pela aceitao dos suprodutos do projeto. O ojetivo #oter a aceitao. Balvez o nome ideal desse processo devesse ser aceitao do escopo+.

1+ Gere#ciame#to do Tempo

Vargas (2014), o gerenciamento do tempo, juntamente com o gerenciamento dos custos, so as mais visveis reasdo gerenciamento de projetos. A grande maioria das pessoas que se interessa por projetos tem como objetivo inicial

controlar prazos, confeccionar cronogramas e redes etc.

Vargas (2014) continua ressaltando a importncia que o gerenciamento de tempo mostra o impacto de

problemas no projeto e no a causa do problema. O gerenciamento do tempo como um termmetro para a febre. Elemostra que algo esta errado, mas no diz qual a razo do problema.


10/22

[ 1 ]

Vargas (2014) ainda conclui, o principal objetivo dessa rea garantir que o projeto seja concludo dentro doprazo determinado.

O tempo o recurso mais precioso de um projeto. Uma vez perdido, n o hcomo recupera-lo. No se podereencontr-lo, no possvel reutiliza-lo aps um tempo de recuperao, sem ele no dpara fazer um emprstimo paracobrir o que foi gasto, no possvel para contratar assessoria de especialista, no da para melhorar o contedo e formatoda comunicao, no da para conversar pessoalmente para deixar claro mal-entendidos, no dpara realizar auditoria nofornecedor para identificar pontos falhos no processo, afirma Jugend (2014).

De acordo com o PMBOK (2014), o Gerenciamento do tempo um conjunto de processos exigidos paraassegurar que o projeto serimplantado no tempo previsto.

PMBOK (2014), Para iniciar o Gerenciamento do Tempo necessrio que se tenha realizado contento adefinio do escopo. Por isso enfatizamos tanto esta questo. Escopos mal definidos levam a retrabalhos deplanejamento, aumentos de custo e aumentos de prazo.

PMBOK (2014), O tempo uma das variveis mais temidas no ambiente de um projeto. Com o objetivo de

maximizar a utilizao do tempo em seus projetos, muitas organizaes tm investido largamente em processos,treinamentos, softwares e outras ferramentas.

PMBOK (2014), Uma das principais preocupaes est relacionada ao custo do atraso de um projeto. Aquantificao do custo do atraso da entrega de um projeto varia de projeto para projeto e depende do momento em queele ocorre. Dentre as principais implicaes do atraso de um projeto, pode-se citar: multas contratuais; perda departicipao no mercado (market share) para a concorrncia devido ao adiamento do lanamento de um novo produto;inviabilizao do projeto (um evento de esporte como a Copa do Mundo de Futebol, por exemplo).

PMBOK (2014), O gerenciamento dos riscos do projeto tambm se constitui em um elemento de grandeimportncia para que o mesmo mantenha o seu cronograma. medida que os riscos so conhecidos, podem-se criarpolticas e planos de ao como resposta aos mesmos, evitando que surpresas ocorram durante a etapa de execuo eafetem negativamente o prazo de uma determinada atividade ou do projeto como um todo.

PMBOK (2014), a partir da definio das atividades pode-se estabelecer o trabalho que serpreciso para gerar osdeliverables do projeto e planejar a distribuio de aes entre os integrantes da equipe envolvida com o projeto. Aquantificao dos recursos necessrios para a realizao das atividades e a alocao destes, tambm depende da definiodas atividades, assim como a apurao do custo do trabalho que serdesenvolvido.

PMBOK (2014) as atividades se constituem na parte mais elementar do projeto. Assim, se faz necess rio que asatividades do projeto recebam muita ateno durante o planejamento e sejam documentadas. A documentao dasatividades permite que seja feita a comparao entre o trabalho que foi planejado para uma determinada atividade e o querealmente foi realizado, facilitando o acompanhamento da evoluo do desenvolvimento das atividades ao longo doprojeto, de forma que se garanta a qualidade das entregas do projeto.

O PMBOK (2014) define algumas ferramentas e tcnicas que podem ser utilizadas no ambiente de projetos paradesenvolver o processo de definio das atividades. Estas ferramentas e tcnicas so: decomposio; planejamento emondas sucessivas; modelos; opinio especializada.

Vargas (2005), diz que o tempo no espera por ningum, principalmente por aquele gerente que constricronogramas baseados em datas impossveis. O cronograma do projeto sempre uma restrio, atmesmo quando a datade termino no crtica. Se um projeto atrasa, na maioria das vezes ele ir consumir um capital que ele no tinhaprevisto, comprometendo tambm, o seu custo, podendo atmesmo causar srias consequncias mercadolgicas para oproduto, ou servio do projeto.

Jugend (2014), a estimativa de durao das atividades no o processo que segue o sequenciamento delas. Antesde estimarmos a durao, importante que se identifique os recursos a serem alocados em cada atividade.

1, Gere#ciame#to do Custo


11/22

[ 11 ]

4ntes de introduzir os conceitos de sistemas de custos se faz necess%rio um alin-amento %sico sore &astos deuma or&anizao, no sentido de equalizar os conceitos e tam#m para que possamos fazer considera6es e compara6escom o amiente de projetos.

Gasto' ?ompra de um produto ou servio qualquer, que &era sacrifcio financeiro para entidade (desemolso),sacrifcio esse representado por entre&a ou promessa de entre&a de ativos (=artins,200H).

Bipos de &asto' Os &astos podem ser classificados em' nvestimentos, ?ustos ou Aespesas (=artins,200H).

nvestimento' Gasto com em ou servio ativado em funo de sua vida Itil ou enefcios atriuveis a perodosfuturos (=artins,200H).

?usto' Gasto relativo a em ou servio utilizado na produo de outros ens e serviosJ so todos os &astosrelativos / atividade de produo.

1e&undo 5liseu =artins' ?>1BO K G41BO 34 LOA>MNO

@ sacrifcio financeiro que a entidade arca para oteno de um produto ou servio esse representado por entre&a oupromessa de entre&a de ativos+ (=artins,200H)

Aespesa' Gasto com ens e servios no utilizados nas atividades produtivas e consumidos com a finalidade deoteno de receitas (=artins,200H).

5m termos pr%ticos, nem sempre # f%cil distin&uir custos de despesas. ode:se, entretanto, propor uma re&rasimples do ponto de vista did%tico' todos os &astos realizados com o produto at# que esteja pronto, so custosJ a partir daso despesas. 4ssim, por exemplo, &astos com emala&ens so custos se realizados no mito do processo produtivo (o

produto # vendido emalado)J so despesas, (apropriao em conta de resultado) no momento em que tais produtos sovendidos.

Ojetivos do ?usto' 4 ?ontailidade de ?ustos, de acordo com Peone (2000), projeta e opera sistemas decustos, determina os custos por departamentos, por funo, por centros de responsailidades, por atividades, por

produtos, por territrios, por perodos e por outros se&mentos, faz a estimao de custos, estaelece padr6es, manipulacustos -istricos, compara custos de diferentes perodos, compara custos reais com custos calculados, determina custosde alternativas, interpreta e apresenta informa6es de custos como um auxlio / &erncia no controle de opera6escorrentes e futuras.


12/22

[ 12 ]

Ae acordo com=QOR (20H;), a &esto de custos em projetos inclui processos envolvidos em estimativas,oramento e controle.

5stimativas de custos S so os custos estimados requeridos para c%lculo dos recursos de um projeto.

Oramento dos custos S a&re&a os custos estimados de atividades estaelecendo o custo total do projeto.

?ontrole de custos S identifica as varia6es de custo e prop6e mudanas no projeto e no oramento.

De acordo com Martins (2001), os custos podem ser classificados da seguinte maneira:

1. Diretos e indiretos;

2. Fixos e variveis;

3. Primrios e de transformao.

Custos diretos e indiretos: A caracterstica dessa classificao a segregao dos custos em cada uma dasunidades de acumulao de custos. De acordo com a figura 3.2, como se a empresa ou entidade fosse dividida emvrios em vrios estoques depsitos onde os recursos so direcionados, e alguns deles (custos diretos) de dirigissemimediatamente para os depsitos prprios, e os outros (custos indiretos) ficassem flutuando sobre eles, aguardando aoportunidade mais adequada para entrar em seu respectivo depsito. Figurativamente, pode-se dizer que, no momento daocorrncia, os custos diretos tm seu destino certo e definido, ao passo que os custos indiretos ficam indecisos sobre seudestino, aguardando ao de um agente externo para ajudar seu direcionamento (Dutra, 2003).

?ustos fixos e vari%veis' 1e&undoPadoveze (2006), os custos diretos e indiretos podem ser classificados em fixose variveis, quando tomamos como referncia o seu comportamento em relao ao volume de produo. Essaclassificao importante, pois permite que os custos sejam adicionados a uma varivel independente, para estudosprospectivos, ou seja, propsitos de previses, oramentos e processos de tomada de deciso para possveis novos cursosde ao.

De acordo com Viana (2005), podemos definir custos fixos e variveis da seguinte maneira:

- Custos Fixos: so todos os custos que a organizao tem, independente da quantidade produzida pelo seuprocesso. Ou seja, um valor constante em termos absolutos, e varivel quando referenciado com as unidadesproduzidas. Logo, quanto maior o volume de produo menor sero custo unitrio de cada unidade.

- Custos Variveis: so custos caracterizados por serem proporcionais produo da empresa. Ele fixo quandoreferenciado s unidades produzidas e varivel em termos absolutos.

Desta forma, quanto maior o nvel de atividade da organizao, maiores sero seus custos variveis. Como porexemplo, podemos citar a matria-prima do objeto.

Custos semivariveis ou semifixos: tm como caracterstica possuir na sua composio uma parcela fixa e outravarivel.


13/22

[ 13 ]

Por exemplo, o custo de manuteno composto basicamente por trs componentes: mo de obra, materiais econtratao de servios externos.

Verificamos que a mo de obra da manuteno pode ser considerada como custo fixo. Lembremos o exemplodos salrios da manuteno eltrica, pois ela estar atuando mesmo quando o nvel de atividade for zero. J oscomponentes materiais e servios contratados sofrero influncia do volume produzido, pois quanto maior a utilizaodos equipamentos, maior sersua necessidade de manuteno (peas e servios especializados).

De acordo com Dutra (2003), podemos definir custos primrios e de transformao da seguinte maneira:

- Custos Primrios: englobam o valor da matria-prima ou do material e da mo-de-obra e, portanto, so

expressos pela soma desses dois custos.

- Custos de Transformao: representam o total de recursos aplicados sobre o custo bsico para transform-lo emoutro bem e so constitudos pela mo-de-obra e custos indiretos.

1 Gere#ciame#to do %isco

Sua anlise e classificao deu-se inicialmente apenas nas bases da sua objetividade ou subjetividade. O fato dejogar uma moeda para obter cara ou coroa um risco classificado como objetivo porque as chances so bem conhecidas.Ou a moeda cai com uma face voltada para cima ou cai com a outra. Mesmo que as sa das sejam incertas, um riscoobjetivo pode ser descrito precisamente em teoria, atravs de um experimento ou pelo bom senso (POSSI, 2006).

Risco um evento ou uma condio incerta que possa prejudicar as chances de sucesso de um projeto tendo efeitopositivo ou negativo em pelo menos um dos seus objetivos. O risco tem origem na incerteza que existe em todos osprojetos. Os riscos conhecidos so os que foram identificados e corretamente analisados, possibilitando assim seremplanejadas as respostas no caso de ocorrncia minimizando os impactos causados (PMBOK, 2014).

Os riscos podem ser organizados dentro de categorias de riscos, que se bem definida deve refletir os princpioscomuns dos riscos para determinada rea de aplicao (PMBOK, 2014):

a) Riscos organizacionais: so todos os riscos que esto ligados poltica e gesto da empresa;b) Riscos de gerncia de projeto: so ligados a todos os eventos que podem fazer com que o gestor do projeto

venha a falhar;

c) Riscos tcnicos, de qualidade ou de desempenho: uso de metas e desempenho irrealista ou muito complexo quepodem afetar o desenvolvimento do projeto, tecnologias no comprovadas, ou mesmo a falta de conhecimento;

d) Riscos externos: qualquer desvio do ambiente ideal do projeto, como um pedido de demiss o, questestrabalhistas, mudana nas prioridades, entre outros.

PMBOK (2014), o gerenciamento de riscos em projetos composto por vrios processos que visam aumentar aprobabilidade e o impacto dos eventos positivos a fim de reduzir a ocorrncia dos eventos negativos evitando ouminimizando os impactos causados por eles. A gerncia de riscos composta pelos processos de planejamento,identificao, anlise, planejamento de respostas, monitoramento e controle de riscos.

A gesto de riscos define uma forma de lidar com imprevistos que ocorrem em projetos, fazendo com quecenrios futuros fiquem dentro de uma faixa aceitvel de risco (VENNCIO, 2010).

O risco de um projeto tem origem na incerteza. Os riscos conhecidos so os que foram identificados e analisados,possibilitando o planejamento de repostas no caso de ocorrncia. Estas respostas refletem o equilbrio da organizaoentre correr riscos e evitar riscos e podem refletir imediatamente no sucesso do projeto (PMBOK, 2014).

O gerenciamento dos riscos, segundo o PMBOK (2014) envolve:


14/22

[ 14 ]

a) Planejamento do gerenciamento dos riscos: o processo iniciado na concepo do projeto e a sua conclusodeve ser nas fases iniciais do planejamento do projeto. um processo de definio de como realizar o gerenciamento dosriscos no projeto em execuo.

b) Identificao dos riscos: o processo que visa determinar quais riscos podem afetar o projeto e documentarsuas caractersticas. A identificao dos riscos um processo iterativo, uma vez que novos riscos podem surgir ou setornar conhecidos durante o ciclo de vida do projeto.

c) Anlise qualitativa dos riscos: o processo de priorizao de riscos para anlise ou ao adicional atravs daavaliao e combinao de sua probabilidade de ocorrncia e impacto. Ela avalia a prioridade dos riscos identificadoslevando em considerao a probabilidade de ocorrncia, impacto nos objetivos, intervalo de tempo para resposta e atolerncia a riscos. Segundo GOMES (2008) o intuito da anlise qualitativa dos riscos confeccionar um documento queaponte numericamente qual a probabilidade o impacto de cada um dos riscos identificados ocorrerem.

d) Anlise Quantitativa dos Riscos: a anlise numrica dos efeitos dos riscos identificados nos objetivos doprojeto. Esta anlise realizada de acordo com os riscos analisados na anlise qualitativa dos riscos que tem impactopotencial nas demandas do projeto. analisado o efeito dos riscos, sendo usada para atribuir uma classificao numricaa fim de avaliar o efeito agregado dos riscos que afetam o projeto.

e) Planejar as respostas aos riscos: um processo focado no desenvolvimento de opes e aes a fim deaumentar as oportunidades e reduzir as ameaas aos objetivos do projeto.

f) Monitorar e controlar os riscos: o processo de implementao dos planos de respostas aos riscos,

acompanhamento dos riscos identificados, monitoramento dos riscos residuais, identificao de novos riscos e avaliaoda eficcia de riscos durante todo o projeto.

As respostas aos riscos planejados, que esto includas no plano de gerenciamento do projeto, so executadasdurante o ciclo de vida do projeto e o monitoramento deve ser continuo para encontrar novos riscos ou mesmo mudanasnos riscos (MATOS; BERMEJO; SALM JUNIOR, 2010).

Dias (2014) afirma que determinados riscos podem no permitir nenhuma medida preventiva vivel que sejaeficiente em termos de custo e benefcio. Nesses casos, a equipe pode elaborar um plano de contingncia, isto umconjunto de aes que ser empregada apenas se o risco ocorrer. Planos de contingencia recebem uma reserva deoramento para a sua execuo.

Dias (2014) conclui nem todo risco seridentificado, e riscos no identificados tambm podem ocorrer.

1.8 5ecessidade e %e"uisitos de Stakeholders

Segundo Carvalho e Rabechini Jr. (2006), um projeto uma organizao de pessoas dedicadas que visam atingirum propsito e um objetivo especfico. Projetos geralmente envolvem gastos, aes ou empreendimentos nicos de altosriscos e devem ser completados numa certa data por um montante de dinheiro, dentro de alguma expectativa de

desempenho. Jna viso de Woiler e Mathias (2008, p. 14), um projeto pode ser entendido como um conjunto deinformaes coletadas e processadas, de modo que simulem uma dada alternativa de investimento para testar suaviabilidade..

Segundo PMBoK 2014 as principais caractersticas dos projetos so que eles so (1) temporrios, possuindo umincio e um fim definidos, (2) planejados, executado e controlado, (3) entregam produtos, servios ou resultadosexclusivos, (4) desenvolvidos em etapas e continuam por incremento com uma elaborao progressiva, (5) realizados por

pessoas e (6) com recursos limitados.Na viso de Carvalho e Rabechini (2006, p. 15), o gerenciamento de projetos inclui planejamento, organiza o,

superviso e controle de todos os aspectos do projeto, em um processo contnuo, para alcanar seus objetivos. Por outrolado, enfatizam-se a aplicao de conhecimento, habilidades, ferramentas e tcnicas como aspectos importantes para agesto de projetos, objetivando atender ou superar as necessidades e expectativas dos interessados (stakeholders).

Kretan et al. (2008) apontam o gerenciamento de stakeholders como a cincia de iniciar, planejar, executar econtrolar projetos atseu fechamento ordenado, compreendendo a aplicao de conhecimentos, habilidades, ferramentase tcnicas para atingir, ou atmesmo exceder, s necessidades e expectativas de todas as partes interessadas.

Para Muto (2006), os stakeholders so as pessoas ou organizaes ativamente envolvidas nos projetos, de maneirapositiva ou negativa ou cujos interesses possam ser afetados com o andamento do projeto ou com o trmino deste. Deacordo com Orth (2009), os stakeholders so pessoas, grupos de pessoas ou entidades que participam ou influenciam oprojeto, de maneira direta ou indireta, com interesses em sua evoluo ou quando so atingidas por seus resultados.

A teoria dos stakeholders, segundo Silveira, Yashinaga e Borba (2005), possui seus vnculos principalmente nasociologia, no comportamento organizacional e na poltica de interesses de grupos especficos. Essa teoria pode serdefina como a formulao e a implementao, pelos administradores, de processos que satisfaam os grupos interessados


15/22

[ 1+ ]

na empresa. A principal funo nesse processo seria a de gerenciar e integrar os relacionamentos e os interesses dosacionistas, funcionrios, clientes, fornecedores, comunidades, entre outros grupos, de forma a assegurar o sucesso daempresa a longo prazo.

De acordo com Brito e Terra (2009), normalmente os stakeholders so distribudos em um grupo mais direto(como empregados e acionistas, instituies financeiras, fornecedores e clientes) e outro um pouco mais indireto (comocomunidades, governo, mdia, grupos de interesse, concorrncia e grupos de defesa de interesses).

Mitchell, Agle & Wood (1997) apud Teixeira e Domnico (2008) separam os fatores que determinam aimportncia dos stakeholders em trs partes: (1) Poder, definido como a fora (coercitiva, utilitria ou regulatria) quepode impor sobre a outra parte em um relacionamento; um ator pode fazer algo que em circunst ncias normais noconseguiria ser feito; (2) Urgncia, definido como quando um relacionamento possui uma natureza sens vel ao tempo ouquando este relacionamento ou pedido importante ou crtico para um stakeholder; exige ateno imediata; (3)Legitimidade, definido como uma percepo ou assuno geralmente aceita que as aes de uma entidade so desejveisou apropriadas dentro de um sistema de normas, leis, crenas e definies.

Para Daychoum (2005) o gerenciamento ativo das partes interessadas aumenta a probabilidade de o projeto nose desviar do rumo por causa de problemas no resolvidos com os stakeholders. Segundo PMI (2004), o gerenciamentode stakeholders consta como um dos processos da rea de gerenciamento de comunicaes e pode ser definido como ogerenciamento das comunicaes, de modo que atenda s necessidades e resolva os problemas com os stakeholders doprojeto, sendo que os grupos de stakeholders envolvidos em um projeto podem ser divididos em: Stakeholders

organizacionais; Stakeholders de produto/mercado; Stakeholders de mercado de capitais (KRETAN, 2009). Ressalta-se aexistncia de dificuldade de se identificar os stakeholders e, para tanto, deve-se primeiro avaliar o ambiente em que seserrealizado o projeto, levando em considerao suas peculiaridades situacionais e locais.

Posteriormente para categorizar os stakeholders os Trentim (2010) sugere a matriz de Savage et al. (1991),

organizando a propenso dos stakeholders em colaborar ou ameaar as estratgias da empresa, sendo: (1) Stakeholdersdispostos a apoiar: alto potencial de cooperao; (2) Stakeholders marginais no so ameaadores nem cooperadores;(3) Stakeholders indispostos a cooperar alto potencial de ameaa; (4) Stakeholders ambguos alto potencial emameaar e em cooperar, influenciados por interesses conflitantes.

Conforme Kretan et al. (2008), o sucesso do projeto est intimamente ligado s garantias de que atendersnecessidades para as quais foi criado. Isso envolve levantar com detalhes as necessidades expl citas e implcitas dosstakeholders e valid-las com as partes interessadas, comprometendo-se a entregar o que foi definido. J Siegelaub(2005) apud Kretan (2008) identifica trs grandes motivos para que o Gerenciamento de Stakeholders seja uma atividadeindispensvel no desenvolvimento do projeto: (1) O envolvimento dos stakeholders crtico para a definio do escopodo projeto e elaborao de estratgias; (2) Em um ltimo momento, so os stakeholders que faro uso dos entregveis doprojeto, com o objetivo de agregar valor ao negcio; (3) O engajamento dos stakeholders produz a assistncia e oentusiasmo necessrios ao desenvolvimento do projeto.

Para Bourne (2006) a relao que existe entre o gerente do projeto e os stakeholders e, ainda, aqueles entre osstakeholders, formam o ambiente do projeto ou esfera de influncia e suporte, do qual um projeto depende para suaexistncia e que precisa ser gerenciado. Nesse sentido, a autora aponta como aspecto importante a identificao e agerncia dos sentidos de influncia.


16/22

[ 1, ]

Capitulo 3 $ Gesto do Projetode um CUBSA

21 Pro6etos de C)7S(Ts22 Gesto de um pro6eto de um C)7S(T

Neste tpico serproposto um modelo de diagrama PERT para o modelo visto e alinhado em sala de aula. Ser realizado e proposto tambm a descrio textual das fases de iniciao, planejamento e modelo de engenharia de sistemasconstrudo em sala de aula. Todo o trabalho a ser realizado neste tpico segue as definies do capitulo 2 e tambm doPMBoK.

221Papel do &ere#te de pro6etos

O gerente de projetos a pessoa alocada pela organizao executora para liderar a equipe responsvel por alcanar osobjetivos do projeto.

Dependendo da estrutura organizacional, um gerente de projetos pode se reportar a um gerente funcional. Em outros

casos, um gerente de projetos pode ser um dos vrios gerentes de projetos que se reportam a um gerente de programas oude portflios que , em ltima instncia, responsvel por projetos de mbito corporativo. Neste tipo de estrutura, ogerente de projetos trabalha estreitamente com o gerente de programas ou gerente de portflios para atingir os objetivosdo projeto e garantir que o plano de gerenciamento do mesmo esteja alinhado com o plano do programa central. O

gerente de projetos tambm colabora estreitamente com outras funes, tal como analista de negcios, gerente degarantia da qualidade e especialistas de outras reas (PMBoK, 5ed).

Ainda de acordo com o PMBoK (5ed), os gerentes de projetos so responsveis pelo atendimento de necessidades: detarefas, necessidades de equipe, e necessidades individuais. Como o gerenciamento de projetos uma disciplinaestratgica crtica, o gerente de projetos torna-se o elo entre a estratgia e a equipe. Os projetos so essenciais para ocrescimento e sobrevivncia das organizaes. Os projetos criam valor na forma de processos de negcios melhorados,so indispensveis no desenvolvimento de novos produtos e servios, e tornam mais fcil para a companhia responder smudanas relativas ao ambiente, concorrncia, e de mercado. Assim sendo, o papel do gerente de projetos torna-se cadavez mais estratgico. Entretanto, a compreenso e aplicao do conhecimento, das ferramentas e tcnicas reconhecidascomo boas prticas no so suficientes para o gerenciamento de projetos eficaz. Alm das habilidades especficas aqualquer rea e das proficincias de gerenciamento geral exigidas pelo projeto, o gerenciamento de projetos eficaz exigeque o gerente de projetos possua as seguintes competncias:

Conhecimento. Refere-se ao que o gerente de projetos sabe sobre gerenciamento de projetos.

Desempenho. Refere-se ao que o gerente de projetos capaz de fazer ou realizar quando aplica seuconhecimento em gerenciamento de projetos.

Pessoal.Refere-se ao comportamento do gerente de projetos na execuo do projeto ou atividade relacionadaa efetividade pessoal abrange atitudes, principais caractersticas de personalidade, e liderana, que fornecema habilidade de guiar a equipe do projeto ao mesmo tempo em que atinge objetivos e equilibra as restriesdo mesmo.

222Gesto do pro6eto de um C)7S(T

Por mais que possa parecer simples um projeto de um CUBSAT estsujeito as mesmas armadilhas de um grandeprojeto e por isso se faz necessrio os mesmo cuidados e ateno as prticas de gesto.

Baseado nas discusses e desenvolvimentos realizados em sala de aula e no conjunto de melhores prticas do PMBoK(5ed) que a fase de planejamento de um CUBSAT decomposta das seguintes fases:

Iniciao Planejamento

Necessidades e Requisitos de Stakeholders

Requisitos de Sistemas

Concepo de Arquitetura Lgica Concepo de Arquitetura Fsica Anlise de Sistemas


17/22

[ 1 ]

223.#iciao

De acordo com o desenvolvimento realizado em sala de aula a fase de iniciao estdividida nas seguintes etapas:1. Desenvolver o termo de abertura do projet

2. Identificar os stakeholdersou classes de stakeholdersem todo o ciclo de vida

3. Elicitar, capturar ou consolidar as necessidades dos stakeholders, expectativas e objetivos4. Identificar as partes interessadas

O desenvolvimento do termo de abertura do projeto deve contemplar o seguinte contedo: Por Que:descrio do projeto; justificativa e contexto; Quem:governana, equipe do projeto e cliente, dentre os principais interessados (stakeholders); Quando:data de incio e prazo de execuo (cronograma preliminar); Onde:abrangncia do projeto; O Que:objetivos, resultados e benefcios, premissas e restries; Como:escopo do projeto trabalho requerido para atingir O Que;

Quanto:oramento a investir no projeto ou uma estimativa inicial que seja minimamente confivel.As etapas 2, 3 e 4 comeam a ser realizadas neste momento e devem ser acompanhadas e revisadas durante todo oprojeto.

Com o termo de abertura desenvolvido e as partes interessadas bem identificadas possvel obter aprovao ealinhamento inicial para iniciar o projeto e comear a prxima etapa que o planejamento.

224Pla#e6ame#to

Neste tpico ser abordado apenas o gerenciamento de escopo, tempo, custo prazo e stakeholders conformealinhamento da equipe. As outras reas de conhecimento contidas no PMBoK vo ficar para um trabalho futuro demelhoria deste trabalho.

O planejamento comea ser realizado assim que o projeto aprovado e iniciado e vai sofrendo revises, melhorias eatualizaes durante todas as fases de planejamento e mesmo durante a execuo do projeto alteraes e revisespodem ocorrer. Por este motivo muito importante nunca perder o foco das informaes que compem oplanejamento do projeto.

No caso do projeto de um CUBSAT que o propsito deste trabalho as reas de conhecimento associadas so:

Gereniciamento do escopo que se decompe nas seguintes etapas: Planejar o gerenciamento do escopo

Coletar os requisitos

Definir o Escopo

Criar a EAP

O produto final desta fase (entregvel) a EAP e atravs dela serpossvel ter um melhor entendimento sobre o quedeve ser realizado, as fases necessrias e quais os responsveis.

Gerenciamnento do tempo que se decompe nas seguintes etapas: Planejar o gerenciamento do cronograma

Definir as atividades

Sequenciar as atividades

Estimar os Recursos da Atividade


18/22

[ 1 ]

Estimar as Duraes das Atividades Desenvolver o Cronograma

O produto final desta fase (entregvel) o cronograma e atravs dele serpossvel estimar os recursos necessriospara que o gerente de projetos possa garantir/permitir que o projeto seja conduzido de maneira adequada dentro

parmetros estabelecidos no escopo e no termo de abertura.

Gerenciamnento do custo que se decompe nas seguintes etapas: Planejar o gerenciamento dos custos

Estimar os Custos

Determinar o OramentoO produto final desta fase (entregvel) o oramento do projeto. Este oramento fruto de estimativas de custos queforam realizadas na fase de elaborao do termo de abertura e que neste momento sofrem um refinamento de clculos.Em muito casos cotaes utilizadas para compor as estimativas em fases iniciais agora so utilizadas para estabelecercontratos para ofornecimento de mo de obra, matria prima e outros.

Gerenciamnento do risco que se decompe nas seguintes etapas: Planejar o Gerenciamento de Riscos

Identificar os riscos Realizar a Anlise Qualitativa dos Riscos Realizar a Anlise Quantitativa dos Riscos Planejar as Respostas aos Riscos

O produto final desta fase (entregvel) o plano de riscos atualzado que se for executado e acompanhado pode evitarque o projeto seja afetado de maneira negativa.

Gerenciamnento de stakeholders que se decompe nas seguintes etapas: Transformar as necessidades priorizadas dos stakeholders em requisitos

Planejar o gerenciamento das partes interessadas

O produto final desta fase (entregvel) o plano de gerenciamento de s takeholdersque se for bem elaborado eacompanhado fornecer uma viso das pessoas que podem influenciar o projeto (tanto de maneira positiva como

negativa) como tambm saberenvolver as pessoas adequadas para cada tipo de deciso que necessite ser tomada.

Todos estes entregveis reunidos vo consolidar o plano de gerenciamento do projeto que nunca poderser analisadoou alterado de maneira isolada. Vale lembrar que uma alterao no cronograma pode afetar diretamente o cronograma,que por sua vez causarreflexos em custos devido ao maior engajamento de mo de obra ou consumo de material.Sem considerar possveis impactos em escopo e risco. O propsito do projeto deve estar o tempo todo na cabea dogestor de projetos. Neste caso o foco no que precisa de fato ser feito muito importante.

22+5ecessidades e %e"uisitos de Sta$eholders

Esta fase praticamente um complemento do planejamento que composto pelas seguintes etapas: Identificar os stakeholders ou classes de stakeholders em todo o ciclo de vida

Elicitar, capturar ou consolidar as necessidades dos stakeholders, expectativas e objetivos

Estabelecer ConOps e Estratgias de Apoio Refinar o Conceito de Operao e outros conceitos de ciclo de vida Priorizar as necessidades dos stakeholders

Identificar os riscos em potencial (ou ameaas e perigos) Transformar as necessidades priorizadas dos stakeholders em requisitos dos stakeholders

Validar o contedo e a relevncia de cada requisito dos stakeholders Sintetizar, registrar e gerenciar os requisitos dos stakeholders e os potenciais riscos associados.

Aps elaborado todas as etapas o plano de gerenciamento do projeto receber um conjunto de informaesfundamentais complementares as informaes construdas e elaboradas anteriormente.

22,8ase de e#&e#haria de sistemas

A fase de engenharia de sistemas onde ocorre o detalhamento e entendimento dos requisitos do produto a serdesenvolvido. Nesta fase todas as informaes coletadas nas fases anteriores vo ser detalhadas e estruturadas, e nestafase que de fato todo o escopo do produto e o que tem de ser feito serconhecido por todos.


19/22


20/22

[ 2 ]

deve possuir para que as necessidades dos stakeholders sejam satisfeitas. Os RS devem estabelecer um conjunto de

objetivos gerais que o sistema devercumprir.A Concepo da Arquitetura Lgica (CAL) tem por objetivo definir, selecionar e sintetizar a arquitetura lgica de um

sistema visando avaliar a funcionalidade e comportamento do sistema e fornecer um panorama para verificar se um

sistema futuro ir satisfazer os requisitos do sistema em todos os cenrios operacionais. O desenvolvimento daarquitetura lgica ajuda a identificar as funes do sistema e os fluxos da informao. A arquitetura lgica trabalha emtorno dos fluxos de dados e deve ser independente das tecnologias a serem utilizadas para desenvolver o sistema.

A Concepo da Arquitetura Fsica (CAF) tem como objetivo definir, selecionar e sintetizar uma arquitetura fsica deum sistema que possa apoiar a arquitetura lgica e satisfazer os requisitos do sistema. A arquitetura fsica deverterpropriedades especficas destinadas a direcionar os desejos e necessidades dos stakeholders e satisfazer os requisitos dosistema (ISO / IEC 26702 2007). A arquitetura do sistema resultante avaliada atravs da anlise do sistema e quandoconcluda torna-se a base para a realizao do sistema.

Finalmente, o processo de Anlise de Sistemas (AS), (tambm chamado de processo de anlise de deciso segundo aNASA (2007)) tem por objetivo ajudar a avaliar as questes tcnicas, alternativas e suas incertezas para apoiar a tomadade deciso. A Anlise de Sistemas pondera as vantagens e desvantagens das solues de sistemas propostos, relacionadascom as seguintes etapas: como os sistemas propostos satisfazem as necessidades estabelecidas pelos stakeholders; qual o

custo relativo do seu desenvolvimento; durao para a concluso prevista de cada atividade componente dodesenvolvimento do sistema e outras controvrsias que possam ocorrer durante o desenvolvimento. Isso pode exigir um

refinamento mais apurado da Definio de Conceitos, visando assegurar que todas as necessidades e desejos dosstakeholders sejam considerados na arquitetura de soluo proposta.O processo de AS composto das seguintes atividades: (1) fornecer uma base rigorosa para a tomada de decis o

tcnica, resoluo de conflitos de requisitos e avaliao de alternativas de solues fsicas; (2) determinar o progressocom relao ao atendimento aos requisitos do sistema; (3) apoiar gesto de riscos; e (4) assegurar que as decises sejamtomadas apenas aps a avaliao dos custos, cronograma, desempenho e efeitos dos riscos na engenharia ou re-engenharia de um sistema (ANSI / EIA, 1998).

Durante esta fase muito importante que o gerente do projeto acompanhe atentamente o desenvolvimento dasatividades e mantenha sempre o foco no propsito do projeto.

Para o projeto ser aprovado necessrio que exista um documento (termo de abertura do projeto) com as informaesnecessrias para os responsveis possam aprovar. Normalmente neste documento existe todo um alinhamento do escopodo projeto com os interesses da instituio e cabe o gerente de projetos manter este foco para que o projeto atinja seuobjetivo.


21/22

[ 21 ]

Bi(liogra)aKIENBAUM, G. S. (2014). A Framework for Process Science and Technology. Technical Report, Loughborough

University, Loughborough. 2014.

PMBoK. Conjunto de Conhecimentos em Gerenciamento de Projetos. Four Campus Boulevard, Newtown Square PA:Project Management Institute 2013, Quinta Edio.

Oliveira, Sergio M. Tcnicas para Gerenciamento de Projetos de Software, Ed. Brasport 2007HELDMAN, Kim - Gerncia de Projetos - Fundamentos, 5 Ed. Elsevier, 2005.AALST, W. van der; WESKE, M; WITRZ, G. Advanced topics in workflow management. Journal of Integrated Design and

Process Science,v. 7, n. 1, p. 58, Mar. 2003.

ASSOCIAO BRASILEIRA DE NORMAS TCNICAS (ABNT) NBR ISO 9000: sistemas de gesto da qualidade fundamentose vocabulrio. Rio de Janeiro, 2005.

CAPABILITY MATURITY MODEL INTEGRATION (CMMI). Software Engineering Institute. Disponvel em:. Acesso em: 28 Dez. 2013.

DEMING, W. E., Qualidade: A Revoluo da Administrao. Marques Saraiva, 1990.

EUROPEAN COOPERATION FOR SPACE STANDARDIZATION (ECSS), ECSS-M-ST-10C - space project management

project planning and implemantation. Noordwijik, The Netherlands: ESA Requirementes and Standards Division, 2009a.______.ECSS-M-ST-40C - space project management configuration and information management. Noordwijik, The Netherlands:

ESA Requirementes and Standards Division, 2009b.

______. ECSS-Q-ST-10C - space product assurance product assurance management. Noordwijik, The Netherlands: ESA

Requirementes and Standards Division, 2008a.

PMBok 5 Edio, Um guia em Gerenciamento de Projetos, 2014

Gerenciamento de Projetos Guia do Profissional - Vol. 1- Abordagem Geral e Definio de Escopo. Ed. Brasport 2006

Possi, Marcus, Gerenciamento de Projetos Guia do Profissional Vol. 3 Fundamentos Tcnicos. Ed. Brasport 2006

Xavier, Carlos Magno da S. Gerenciamento de Projetos: como definir e controlar o escopo do projeto/Carlos Magno da S. Xavier

So Paulo: Saraiva, 2006.

Dias, Fernando R. T. Gerenciamento Dos Riscos Em Projetos: Ed Elsevier 2014

VENNCIO, J. Gesto de Riscos em Projetos de Software. 2010. Monografia Universidade Federal de Pernambuco.

GOMES, F. Plano de Gerenciamento de Riscos do Projeto. Disponvel em: http://msofficeproject.wordpress.com/2008/09/01/plano-de-gerenciamento-deriscos-do-projeto. 2008. Acesso em: 21/03/2013.

CARVALHO, Marly Monteiro de. RABECHINI Jr., Roque. Construindo competncias para gerenciarprojetos: teorias e casos. So Paulo: Atlas, 2006.

WOILER, Samso; MATHIAS, Washington Franco. Projetos, elaborao, anlise. 2 ed. So Paulo: Atlas,2008.

KRETAN , Agostinho. et al. Gerenciamento de stakeholders: um fator critico para o sucesso em projetos Revista Mundo Project

Management . So paulo, n.24, v.4, p.62 , dezembro 2009.MUTO, Claudio Adonai. Exame PMI: a bblia. Rio de Janeiro: Brasport, 2006.SILVEIRA, Alexadre; YASHINAGA, Claudia; BORBA, Paulo. critica a teoria dos stakeholders como funo objetocorporativa. Caderno de Pesquisas em Administrao, So Paulo, v. 12, n. 1, p. 33-42, janeiro/maro 2005.BRITO, Antnio Carlos; TERRA, Jos Claudio C. Posicionamento Estratgico e Sistematizao da Gesto dos Stakeholders.Disponvel em Biblioteca Terra Forum Consultores, 2009.DAYCHOUM, Merhi. Gerncia de projetos: programa delegacia legal. Rio de Janeiro: Brasport, 2005PMI. A Guide to the Project Management Body of Knowledge Third Edition (PMBOK Guide). Newtown Square, PA: Project

Management Institute, 2004.

TRENTIM, Mrio, H. Gerenciamento de stakeholders: o case BP Golfo do Mxico. Revista Mundo Project, ano 6, n 34 ago/set de2010

MARTINS, Eliseu. Contabilidade de Custos. Ed. Atlas, 8ed, 2001.

LEONE, George Sebastio Guerra. Custos Planejamento, Implementao e Controle. Ed. Atlas, 3ed, 2000.
http://resources.sei.cmu.edu/library/asset-view.cfm?assetid=19290http://resources.sei.cmu.edu/library/asset-view.cfm?assetid=19290


22/22

DUTRA, RenGomes. Custos: Uma Abordagem prtica. Ed. Atlas, 5ed, 2003.PADOVEZE, Clovis Lus. Curso Bsico Gerencial de Custos. Ed. Thomson, 2ed, 2006.VIANA, Herbert Ricardo Garcia. Lies Preliminares Sobre Custos Industriais. Ed. Qualimark, 1ed, 2005.

Martinelli, Fernando. Fundamentos de Projetos. IESDE Brasil SA. 2009

Vargas, Ricardo. Manual Prtico do Plano do Projeto - 5 Ed: Utilizando o PMBOK Guide - Brasport 2014.

Vargas, Ricardo. Gerenciamento de Projetos: Estabelecendo diferenciais competitivos. 6 Ed - Brasport 2005.

Jugend, Daniel. Gesto de Projetos: teoria, prtica e tendencias. Elsevier, 2014.

Documents

Trabalho Grupo PLM 07-09