O impacto da metodologia de desenvolvimento de software GEM na competitividade em equipas de home-banking

Estudo de caso: Esprito Santo Informtica

Bruno de Sousa Costa Marques Coelho

Projeto de Tese de Mestrado em Gesto / 7 edio Orientador: Professor Doutor Nuno Goulart Brando Co-Orientador: Professor Dr. Jos Lopes Costa

Lisboa 2012 1

ndice Geral

1 - Ttulo e Subttulo Provisrio .......................................................................... 4 2 - Tema ............................................................................................................. 4 3 - Objetivos da Investigao ............................................................................. 4 4 - Problemtica de Partida ................................................................................ 4 5 - Estado da Arte .............................................................................................. 7 5.1 Teorias de Liderana ............................................................................. 7 5.1.1 Teoria dos Traos dos Lderes ........................................................ 7 5.1.2 Liderana Comportamental ............................................................. 8 5.1.3 Liderana Servidora ........................................................................ 8 5.1.4 Liderana Situacional .................................................................... 11 5.1.5 Liderana Transformacional .......................................................... 12 5.2 Metodologias de Desenvolvimento de Software .................................. 15 5.2.1 Scrum ............................................................................................ 19 5.2.2 Lean IT .......................................................................................... 20 6 - Esboo das Hipteses em Investigao ..................................................... 24 7 - Metodologia................................................................................................. 24 7.1 - Enquadramento da Empresa ................................................................ 24 7.2 - Estratgia Metodolgica ....................................................................... 25 8 - Relevncia da Investigao ........................................................................ 26 9 - ndice Geral (provisrio) da Investigao .................................................... 26 10 - Bibliografia ................................................................................................ 28 10.1 Referncias Bibliogrficas ................................................................. 28 10.2 Webgrafia .......................................................................................... 30 10.2 A consultar ......................................................................................... 30 11 - Planeamento (Cronograma) da Investigao ............................................ 31 12 - Orientador / Co-Orientador........................................................................ 31

ndice de Figuras
Figura 1 Evoluo dos indicadores do Chaos Report desde 1994 at 2009 ... 5 Figura 2 Fatores crticos de Sucesso de um projeto ....................................... 5 Figura 3 - Fatores crticos de Sucesso do Chaos Report de 2009 ..................... 6 Figura 4 Lucros Southwest em 2004 ............................................................... 9 Figura 5 Adaptado de Blanchard e Hersey (1986) ........................................ 11 Figura 6 - O quadro geral de um projeto de desenvolvimento de software. ..... 15 Figura 7 - A metodologia Waterfall segundo Royce ......................................... 17 Figura 8 - Os princpios Lean organizados numa pirmide .............................. 22 Figura 9 - A pirmide organizacional invertida do Lean ................................... 23 Figura 10 - Estrutura Empresarial da Esprito Santo Informtica ..................... 25

ndice de Tabelas
Tabela 1 - Indstria de Software vs Indstria Tradicional................................. 16

1 - Ttulo e Subttulo Provisrio

O impacto da metodologia de desenvolvimento de software GEM na competitividade em equipas de home-banking Estudo de caso: Esprito Santo Informtica

2 - Tema
Liderana e Metodologias de Desenvolvimento de Software.

3 - Objetivos da Investigao
A investigao ser baseada num estudo de caso sobre a equipa responsvel pelos Canais Diretos, do sistema de home-banking,1 do Banco Esprito Santo (BES) Os objetivos da investigao so, resumidamente, os seguintes: Analisar o impacto que a metodologia de desenvolvimento de software (GoTo Evolution GEM) teve na produtividade e competitividade de uma equipa de desenvolvimento de software, nomeadamente ao nvel dos indicadores on-time2, on-budget3 e on-target4 dos projetos realizados entre 2010 e 2011; Perceber o contributo da Liderana para na implementao da metodologia GEM.

4 - Problemtica de Partida
A Standish Group International (SGI) uma empresa, formada em 1985, que se dedica a investigar o desempenho dos projetos de desenvolvimento de software e a razo pela qual eles falham. Segundo a SGI (2001:2), as definies de um projeto ter sucesso, ser um falhano e ou ser desafiado so as seguintes: Sucesso: entregar um projeto on-time, on-budget e com os requisitos desejados Desafiado: atrasado, para alm do oramentado e/ou com menos requisitos do que o combinado

Aplicao alojada na web que permite a um cliente de uma instituio bancria realizar operaes sobre as contas que controla 2 on-time significa dentro do prazo combinado com o cliente 3 on-budget significa dentro do oramento disponvel para o projecto 4 on-target significa entregar os requisitos funcionais que o cliente pediu

Falhano: cancelado antes de ter sido concludo ou entregue e nunca usado.

Apesar das dcadas de experincia a desenvolver software, ainda em 2009, as empresas de desenvolvimento de software apenas conseguiram que 32% dos seus projetos tivessem Sucesso! Historicamente, a percentagem de sucesso nunca ultrapassou os 35% desde 1994 (SGI, 2009).
Figura 1 Evoluo dos indicadores do Chaos Report desde 1994 at 2009

Fonte: SGI (2009)

O Chaos Report (SGI, 2001) indica tambm os dez fatores crticos de sucesso dos projetos de desenvolvimento de software. Os primeiros quatro fatores de 2001 contribuem em 60% para o Sucesso do projeto e esto focados em fatores humanos, nomeadamente a liderana.
Figura 2 Fatores crticos de Sucesso de um projeto

Fonte: SGI (2001, p. 4)

Em 2009, os quatro primeiros fatores crticos de Sucesso representam 61% (SGI, 2009). Mais uma vez, os fatores so baseados em questes de liderana do que no know-how especfico sobre desenvolvimento de software.

Figura 3 - Fatores crticos de Sucesso do Chaos Report de 2009

Fonte: (SIG, 2009)

Os dados do Chaos Report da Standish Group (SGI, 2009) revelam que as metodologias atuais, no esto a conseguir responder s necessidades tanto das equipas de desenvolvimento como dos clientes e utilizadores do software. As metodologias atuais de desenvolvimento de software no so competitivas porque no esto focadas em melhorar o desempenho da equipa ou em inovar. Desta forma, projetos com caratersticas semelhantes no so desenvolvidos nem em menos tempo nem melhores que os anteriores. Como no conseguem determinar se necessrio ou no intervir sobre o funcionamento normal da equipa, as metodologias correntes introduzem ainda ineficincias no seu processo de desenvolvimento. Uma das ineficincias a criao de reunies obrigatrias dirias, onde toda a equipa pra para tentar determinar se existe algum desvio face ao planeado, mesmo quando esse desvio foi justificado e benfico para o cliente. Isto implica que mesmo quando tudo corre como planeado: a equipa pra. A motivao da equipa de desenvolvimento, algo essencial para criar e manter a energia necessria para ter um desempenho acima da mdia, no trabalhada pelas metodologias de software atuais. Nestes casos, os elementos da equipa sentem que esto envolvidos em algo que est a ser feito para eles e no com eles. A avaliao do desempenho individual, que essencial no s para reconhecer quem est a contribuir positivamente para o sucesso da equipa mas tambm para ajudar ou redirecionar os esforos de quem no est a conseguir, no est includo nas metodologias atuais.

5 - Estado da Arte
A globalizao e a revoluo tecnolgica levaram o Mundo a negociar num contexto econmico extremamente competitivo. O mercado onde as equipas de desenvolvimento de software esto inseridas no exceo. Neste tipo de realidade econmica, a liderana desempenha um papel fundamental no sucesso das equipas de desenvolvimento de software.

5.1 Teorias de Liderana

5.1.1 Teoria dos Traos dos Lderes
Uma das primeiras teorias sobre liderana a Teoria do Homem Extraordinrio estudada pelo Historiador Thomas Carlyle (2001). Para Carlyle (2001, p. 5), a Histria Universal, a histria do que o homem concretizou neste mundo, no fundo a Histria dos Homens Extraordinrios que trabalharam aqui. Eles foram lderes de homens, estas pessoas extraordinrias; os modeladores, os padres e, num sentido lato, criadores do que quer que seja que a massa geral de homens conseguiu fazer ou alcanar; todas as coisas que ns vemos erguidas e realizadas no mundo so propriamente o resultado material externo, a realizao prtica e a personificao dos Pensamentos que habitavam nos Homens Extraordinrios enviados ao mundo; a alma da histria de todo o mundo, pode ser justificadamente considerada, a histria destes. As investigaes relacionadas com esta teoria levaram a que os investigadores se concentrassem no estudo das caratersticas dos lderes que, por sua vez, resultou na criao da teoria com mesmo nome a Teoria dos Traos dos Lderes (Kirkpatrick e Locke, 1991). Esta teoria assume que os lderes detm um conjunto de caratersticas especiais que os permitem estar preparados para assumir este papel. Kirkpatrick e Locke, investigadores desta teoria, identificaram seis traos nicos dos lderes, a saber: (1) a fora, composta pela concretizao, ambio, energia, tenacidade e iniciativa; (2) a motivao para liderar; (3) a honestidade e integridade; (4) a autoconfiana e a habilidade cognitiva; (5) o conhecimento do negcio; (6) e outros traos, tais como, o carisma, a criatividade, a originalidade e a flexibilidade (Kirkpatrick & Locke, 1991 : 49-56).

Recentemente, Jim Collins (2001, p. 21) identificou a Humildade e Dedicao como duas caratersticas fundamentais dos Lderes de Nvel 55. Este tipo de lderes canalizam as necessidades do seu ego para longe deles e para o objetivo maior de construir uma empresa extraordinria. Isto no quer dizer que os Lderes de Nvel 5 no tenham ego ou interesse em si prprios. Na verdade, eles so incrivelmente ambiciosos mas a sua ambio acima de tudo e em primeiro lugar para a instituio, no para eles. No entanto, apesar de Jim Collins (2001) referir que estes lderes no esto focados neles prprios importante referir que os alvos do foco destes lderes (os seus valores, o seu trabalho, a sua empresa e a causa) representam quem eles so. Tal como o pintor orgulhoso no aponta para si prprio, mas sim para os quadros que representam quem ele , o Lder de Nvel 5 aponta para aquilo que o representa os resultados que a sua empresa atingiu.

5.1.2 Liderana Comportamental

As teorias de liderana que baseavam-se em caratersticas inatas dos lderes para justificar o impacto das suas aes, foram alvo de crticas por parte de alguns investigadores. Foram realizadas novas investigaes com o objetivo de estudar no os traos dos lderes, mas antes o seu comportamento. Estes investigadores acreditavam que se conseguissem identificar os padres comportamentais chave dos lderes extraordinrios, conseguiriam fazer com que a liderana pudesse ser ensinada. Assim, surgiu a Teoria da Liderana Comportamental (Blanchard & Johnson, The One Minute Manager, 2003). Ken Blanchard e Spencer Johnson (2003) criaram uma teoria de liderana conhecida como Gesto-Minuto (One Minute Management) que defende que o comportamento de um gestor extraordinrio baseia-se em tirar um minuto extra para garantir que os colaboradores conhecem quais so os seus objetivos; andar pela organizao para apanhar algum a fazer bem as tarefas e dar um elogio de um minuto; garantir que se algum no est a fazer o que deveria estar, redirecionado se for um aprendiz ou, se j devia saber como fazer e um problema de atitude, recebe uma reprimenda num minuto (Blanchard, 2008).

5.1.3 Liderana Servidora

Dentro das teorias da liderana comportamental existe uma que se foca no papel de servo do lder. Este estilo de liderana, definido pela primeira ver por Robert Greenleaf (1991), conhecido como Liderana Servidora. Greenleaf (1991 : 9) diz que o Lder-Servidor um servo primeiro. Comea com um desejo natural de, em primeiro lugar, querer servir. Depois a escolha
5

Lderes de Nvel 5 a forma pela qual Jim Collins se refere aos lderes que levaram as suas empresas a passarem de boas a extraordinrias, numa investigao conhecida como Good to Great

consciente leva-o a aspirar a liderar. Ele drasticamente diferente da pessoa que , em primeiro lugar, um lder, talvez devido necessidade de satisfazer os desejos de poder ou de adquirir bens materiais. Para essa pessoa, servir vai ser uma escolha tomada mais tarde depois da liderana estar estabelecida. Como a Liderana Servidora mistura dois conceitos opostos segundo o ponto de vista de liderana tradicional baseado na Autoridade inspirado no modelo militar e popularizado durante a Era Industrial, alguns investigadores criticaram este estilo. Quay (1997 : 83) referiu que mais inteligente confiar na competio e no equilbrio de poderes do que confiar que aqueles que esto no poder so justos. Brumback (1999) classificou a Liderana Servidora como um conjunto de ideias obscuras e impraticveis (Brumback, 1999). Bridges (1996 : 17) disse que no existe nada de melhor ou mais elevado sobre este tipo de liderana. [...] simplesmente uma ferramenta diferente para uma tarefa diferente. Para Blanchard e Hodges (2005), o motivo pelo qual no existem mais lderes a usar este estilo e existirem este tipo de crticas porque as pessoas esto a confundir dois papis diferentes do lder: definir a Viso, atravs da Liderana Estratgica, e garantir a sua Implementao bem-sucedida, atravs da Liderana Operacional. Enquanto a definio da Viso usa o primeiro papel deste estilo Liderar, a Implementao usa o segundo Servir, isto , garantir que as pessoas responsveis pela operao tm tudo o que precisam para terem sucesso (Blanchard, 2010). A Southwest Airlines (2004) um exemplo que a Liderana Servidora no uma teoria de liderana impraticvel. Na verdade, os resultados obtidos e a competitividade atingida atravs da utilizao deste estilo de liderana so bem reais. Segundo os dados disponveis no site da empresa: a) Os lucros da empresa superam em muito os lucros dos seus adversrios, ano aps ano - durante dcadas
Figura 4 Lucros Southwest em 2004

Fonte: Garryson e Keller (2004 : 6)

b) 1.5 bilies de clientes satisfeitos e leais empresa desde 1971 Em 21 de Junho de 2011, American Customer Satisfaction Index nomeou Southwest como a melhor no ndice de Transporte para Satisfao do Cliente. Em 21 de Maio de 2011, Consumer Reports classificou Southwest Airlines como a melhor Transportadora Area no Servio ao Cliente. Em Maro de 2011, Keynote Competitive Research classificou southwest.com como a melhor no inqurito de Experincia ao Cliente 2011 para websites de viagens. Nomeada vencedora do Prmio Stevie para a Empresa de Transportes do Ano pela International Business Awards pelo extraordinrio desempenho e servio ao cliente.

c) 37000 empregados que adoram trabalhar na empresa Em Dezembro de 2010, Southwest Airlines foi classificada como a melhor empresa para trabalhar pela Glassdoor.com., numa lista de 50 melhores lugares nos E.U.A. Southwest Airlines foi reconhecida como a Melhor Empregadora numa lista de 100 Military Friendly Employers G.I.Jobs de 2011.

Para alm do estudar apenas o comportamento dos lderes, os investigadores de liderana comearam tambm a analisar como que o seu comportamento variava em funo das situaes.

10

5.1.4 Liderana Situacional

Este tipo de teoria de liderana ficou conhecido como Liderana Situacional e foi desenvolvida por Blanchard e Hersey (1986).
Figura 5 Adaptado de Blanchard e Hersey (1986)

A Liderana Situacional, segundo Blanchard e Hersey (1986) defende que existem quatro estilos de liderana: E1 - Dirigir (Telling): os lderes dizem s pessoas exatamente o que fazer e como fazer supervisionando a execuo da tarefa; E2 - Orientar (Selling): os lderes no dizem simplesmente o que fazer e como fazer. Eles dedicam-se a explicar o que est envolvido nas tarefas vendendo a direo tomada de forma a ter o compromisso da equipa para atingir os resultados. Adicionalmente, o lder investe em desenvolver as capacidades da equipa, atuando como um coach (treinador); E3 - Apoiar (Participating): os lderes no se focam tanto na direo escolhida mas mais em garantir que a equipa tem acesso aos recursos que precisa para atingirem os resultados, facilitando a tomada de decises; E4 Delegar (Delegating): os lderes delegam a execuo da tarefa inteiramente equipa, monitorizando o seu progresso e ficam menos envolvidos na tomada de decises. 11

Cada estilo de liderana, ainda segundo Blanchard e Hersey (1986), deve estar alinhado com o nvel de maturidade dos liderados, a saber: O Participante empolgado: est empenhado em participar mas no tem os conhecimentos para conseguir realizar a tarefa com sucesso (E1); O Aprendiz desiludido: perdeu um pouco do seu empenho porque desiludiu-se com o seu desempenho e com a realidade do seu trabalho. Apesar de j ter desenvolvido algumas capacidades ainda no consegue ter o sucesso desejado na execuo das tarefas (E2); O Executante capaz mas cauteloso: j tem as capacidades necessrias para realizar as tarefas mas no est completamente confiante que vai ter sucesso ou simplesmente no est disposto ou comprometido a trabalhar na tarefa (E3); O Profissional autoconfiante: est comprometido com os objetivos traados, tem as competncias, tem autonomia e confiana suficiente nas suas capacidades de atingir os resultados (E4). Para alm de ser importante identificar qual o grau de maturidade do colaborador para escolher um estilo de liderana, Blanchard e Blanchard (2008), refere que a chave para o sucesso desta abordagem garantir que o colaborador sabe que est a participar no processo. Por outras palavras, significa que o lder deve garantir que est a fazer isto com os colaboradores e no para eles. De outro modo podem ocorrer alguns mal entendidos (Blanchard & Blanchard, 2008): Por um lado, o participante empolgado pode no perceber porque que o seu lder est constantemente no s a dizer o que fazer, mas tambm mostrar como se faz o seu trabalho. Pode confundir com falta de confiana. Por outro lado, o executante capaz mas cauteloso pode no perceber porque que lder est mais distante... Pode pensar que o seu trabalho no relevante. Uma das diferenas que Collins (2001) identifica entre os Lderes de Nvel 5 e os de 4, que os primeiros preparam os seus seguidores para evolurem de modo a conseguirem tomar o seu lugar na organizao, fazendo-a crescer e prosperar, enquanto os segundos no o fazem.

5.1.5 Liderana Transformacional

A liderana ento um processo que tem o potencial de transformar as pessoas envolvidas. A teoria que estuda este processo chama-se Teoria Transformacional.

12

Segundo James Burns (1978), a liderana transformacional ocorre quando lderes e seguidores fazem com que ambos evoluam para um nvel mais elevado de moral e motivao. Ainda segundo o autor a ao fundamental do lder induzir nas pessoas a conscincia ou a perceo do que eles sentem para que sintam as suas verdadeiras necessidades de forma to forte, para definir os seus valores de forma to significativa, de modo a faz-los mover em aes com propsito. Bernard Bass (1990 : 22) continuou os estudos de Burns e caraterizou a Liderana Transformacional baseando-se em quatro caratersticas destes lderes: Carisma ou Influncia Idealizada: a capacidade de se comportar de forma integra para com os seus valores causando no s admirao a um nvel emocional como tambm inspirando confiana nos seguidores; Motivao Inspiracional: a capacidade de comunicar uma viso atraente e inspiradora para os seus seguidores. Esta capacidade leva os seguidores a terem um forte sentido de propsito e a estarem motivados a agir; Estimulao Intelectual: a capacidade de desafiar o status quo, assumir riscos e promover a capacidade de ultrapassar obstculos na execuo da misso nos seus seguidores; Ateno ou Considerao Individualizada: a capacidade do lder de responder s necessidades e receios dos seguidores e de agir como um coach que os ajuda a desenvolver as capacidades de cada um atingir os objetivos.

Enquanto estes investigadores tenderam a focar-se primordialmente na transformao que ocorre nos seguidores, Blanchard e Hodges (2005) focaram-se na transformao que ocorre no lder. 1. O Corao - saber no s quem mas tambm de quem . Saber quem implica saber quais so os valores que defende, a viso que tem e a misso que pretende cumprir. Saber de quem implica saber qual a quem que o lder responde. 2. A Cabea - representa o sistema de crenas do Lder e a sua perspetiva das suas funes enquanto lder: a. Um papel visionrio - definir o caminho e o destino. Segundo o dicionrio etimolgico Merriam-Webster Unabridged, as palavras lead (liderar), leader (lder) e leadership (liderana) partilham a mesma raiz: to go (ir). Um papel de implementao - servir ao encarregar e ajudar outros a concretizar a viso 13

b.

3. As Mos - representam as aes do lder como resultado daquilo que so a sua cabea e o seu corao. Tal como Peter Drucker (1964) definiu que liderar significa atingir resultados atravs das pessoas, da mesma forma Blanchard e Hodges (2005) referem que o lder deve ser um perfomance coach6. Para ser um performance coach eficaz existem trs partes que devem cumpridas todos os dias: Planeamento de desempenho: tanto o lder como o liderado devem concordar e definir qual o desempenho esperado, o que suposto atingir e qual o deadline. Coaching dirio: depois de definido qual o desempenho esperado, o lder deve garantir que, dia aps dia, os seus colaboradores esto alinhados para atingir os objetivos definidos. Por outras palavras, depois de entregar o exame final, o lder encarrega-se de ensinar as respostas aos seus colaboradores. Avaliao do desempenho: aps ter chegado ao deadline comparado desempenho esperado com o realizado. Atravs deste processo possvel identificar o que deve ser repetido e o que deve ser melhorado.

4. Os Hbitos - representam as atividades s quais o lder se dedica de forma consistente. Liderar mais do que saber teorias. Existem lderes que sabem o que suposto fazerem e que ainda assim no o fazem. Porqu? Porque o que eles sabem que suposto fazer no est alinhado com o que eles so. Esta realidade revela-se quando as suas aes dirias no esto alinhadas com aquilo que promovem na teoria. Isto especialmente notrio em situaes de elevado stress quando a presso impede-os de pensar com clareza, acabando por revelar quem realmente so. O resultado final que a sua autoridade como lder afetada. Os lderes extraordinrios em situaes de stress no precisam de pensar o que fazer. Eles sabem o que fazer porque todos os seus pensamentos, palavras, aes e hbitos at aquele momento, preparam o seu carter para atingir o seu destino: vencer! O que fazemos repetidamente representa quem somos. A perfeio impossvel de atingir. No entanto, a excelncia possvel atingir porque o hbito de sistematicamente nos dedicarmos a aperfeioar e melhorar quem somos.
6

Treinador de desempenho

14

5.2 Metodologias de Desenvolvimento de Software

A definio da palavra Metodologia, de acordo com (Lexicoteca, 1985, p. 156), um conjunto de regras para o ensino de uma cincia ou arte. A diferena entre Mtodo e Metodologia, segundo Royce (1998), que um mtodo um conjunto razoavelmente completo de regras e critrios que estabelecem uma maneira precisa e repetvel de desempenhar uma tarefa e chegar a um resultado pretendido enquanto uma metodologia um conjunto de mtodos, procedimentos e padres que definem uma sntese integrada de abordagens de engenharia para o desenvolvimento de um produto. Segundo Cockburn (2000 : 65), as metodologias de desenvolvimento de software podem variar entre as metodologias m-pequeno, descrevendo algumas tcnicas e noes de desenho para alguns papis e as metodologias M-Grande que codificam o mximo possvel sobre a maneira de trabalhar processos, tcnicas e os padres fazendo apenas parte do quadro geral. O que Cockburn designa por quadro geral tudo o que est relacionado com um projeto de desenvolvimento de software.
Figura 6 - O quadro geral de um projeto de desenvolvimento de software.

Fonte: Cockburn (2000 : 65)

As caratersticas da indstria do desenvolvimento de software so diferentes das caratersticas da indstria tradicional de fabrico de produtos fsicos. De acordo com Karlstrm (2004 : 24), existem seis caratersticas que as diferenciam:

15

Tabela 1 - Indstria de Software vs Indstria Tradicional

Software Construdo uma vez Custo baixo de reproduo Muito flexvel Intangvel Cliente frequentemente indeciso Custo elevado de manuteno
Fonte: Karlstrm (2004)

Indstria Tradicional Sempre a ser construdo Custo alto de reproduo Inflexvel Fisicamente presente Cliente determinado Custo de manuteno relativamente baixo

O fato do desenvolvimento de software ter um custo de reproduo baixo, ser bastante flxivel e intangvel fez com que, no incio dos projetos de desenvolvimento de software, a necessidade de seguir uma determinada metodologia de desenvolvimento no fosse percebida. Este perodo ficou conhecido pelo mesmo nome do modelo utilizado para desenvolver os projetos: programa-e-arranja (code-and-fix). O programa-e-arranja baseia-se em dois passos: 1) Escrever algum cdigo; 2) Arranjar os problemas do cdigo. (Boehm, 1998 : 61-62) As limitaes principais do modelo programa-e-arranja so: a) o custo de manuteno elevado depois da correo de vrios bugs7; b) software rejeitado pelo cliente ou desenvolvido novamente para estar alinhado com as necessidades do cliente; c) o custo elevado das alteraes ao cdigo para que este seja testado com sucesso e esteja preparado para evoluir (Boehm, 1998 : 62-63). As primeiras metodologias de desenvolvimento de software foram desenhadas para responder s caratersticas da indstria tradicional e s limitaes do modelo programa-e-arranja.

Bug a designao conhecida no mundo do desenvolvimento de software sempre que existe um comportamento anmalo no programa desenvolvido

16

Figura 7 - A metodologia Waterfall segundo Royce

Fonte: Royce W. (1970)

A metodologia Waterfall, criada em 1970, um exemplo clssico de uma metodologia preparada para a realidade da indstria tradicional. Na verdade, a metodologia nasceu com Royce (1970 : 329), que admitiu acreditar no conceito, mas a implementao descrita na figura acima arriscada e convida o falhano. Ainda assim, ao introduzir as fases de anlise de requisitos do sistema, do software e da aplicao antes do desenvolvimento da aplicao, a metodologia Waterfall pretende que o produto final esteja preparado com menos bugs e um custo de manuteno e de evoluo baixo. Para alm da diviso por fases, adicionou ainda a noo de a) feedback loops entre as etapas e b) a prototipagem no incio do cclo de vida do software. Para Boehm (1998 : 63), a principal desvantagem do modelo Waterfall a nfase em ter a documentao completamente elaborada como um critrio de trmino das fases de anlise de requisitos. As Metodologias geis, segundo Karlstrm (2004 : 35-36) surgiram como uma reao dos processos mais rigorosos utilizados durante o terceiro perodo dos processos de engenharia de software. O desenvolvimento destes processos ocorreu em paralelo at ao fim dos anos 90. As metodologias mais comuns deste tipo, segundo so: Extreme Programming (XP): XP foi criado por Ward Cunningham e Kent Beck e involve 12 prticas que individualmente no so novas para a comunidade de Engenharia de Software. A metodologia tornou17

se difundida por volta do ano 2000 e uma verso mais atualizada est atualmente a ser publicada. Cockburns Crystal Family: Cristal foi desenvolvida por Alistair Cockburn no incio dos anos 90 com o foco principal de melhorar a comunicao nos projetos de software. Era pretendido incluir trs verses para tamanhos diferentes de projetos, mas apenas a verso mais pequena foi terminada at agora. Adaptative Software Development (ASD): ASD foi criada por Jim Highsmith. O mtodo foca-se mais na filosofia por detrs da abordagem de desenvolvimento em vez das prticas individuais. Atualmente considerada um complemento da Crystal, enquanto que os detalhes na Crystal complementam a filosofia da ASD. Scrum: Scrum foi criado por Ken Schwaber. O mtodo considerado um meta-processo ou invlucro, independente da metodologia de desenvolvimento a ser usada. , por exemplo, bastante comum usar-se uma combinao de Scrum e XP. Feature Driven Developement (FDD): FDD foi desenvolvida por Jeff De Luca e Peter Coad. FDD um processo designado para produzir resultados frequentes e tangveis e uma coleo das melhores prticas. Dynamic System Development Method (DSDM): FDD uma plataforma focada em entregar uma soluo de qualidade rapidademente. O mtodo foca-se especificamente no desenvolvimento incremental, envolvimento do utilizador e fazer o que mais importante primeiro.

Os mtodos geis tm como base os princpios includos no Manifesto para o Desenvolvimento gil de Software (Beck, et al., 2001): Indivduos e interaes mais do que processos e ferramentas; Software funcional mais do que documentao abrangente; Colaborao com o cliente mais do que negociao contratual; Responder mudana mais do que seguir um plano. Ou seja, apesar de reconhecermos valorizamos mais os itens esquerda. valor nos itens direita,

Como na organizao alvo do caso de estudo, explorado nesta investigao, usado Scrum e LEAN IT, estas metodologias so exploradas em maior detalhe nesta reviso terica.

18

5.2.1 Scrum
Segundo o seu guia oficial, descrito por Schwaber & Sutherland (2011 : 3), o Scrum definido como uma plataforma atravs da qual as pessoas podem trabalhar problemas adaptativos complexos, enquanto entregam, de forma produtiva e criativa, produtos com o maior valor possvel. As fundaes do Scrum so a teoria emprica de controlo de processos, ou empirismo. Esta teoria defende que o conhecimento surge da experincia e da tomada de decises baseando-se no que conhecido (Schwaber & Sutherland, 2011 : 4). O Scrum tem trs pilares: Transparncia: os aspetos significativos do processo devem ser visveis pelos responsveis da entrega. A transparncia requer ainda que exista um padro comum para que os observadores partilhem um entendimento comum (por exemplo: importante que exista uma definio do que consiste uma tarefa estar Concluda (Done); Inspeo: as entregas devem ser inspecionadas para garantir que existe progresso em direo ao objetivo traado ou detetar eventuais desvios; Adaptao: ao ser detetado um desvio fora dos limites aceitveis, de tal forma que o seu produto seja inaceitvel, deve ser realizado um ajustamento o mais depressa possvel para minimizar desvios adicionais. (Schwaber & Sutherland, 2011 : 4)

A Equipa do Scrum, segundo (Schwaber & Sutherland, 2011 : 5-6,) constituda pelo Dono do Produto, a Equipa de Desenvolvimento e o Mestre Scrum (Scrum Master). As Equipas do Scrum pretendem ser multifuncionais contendo todas as competncias necessrias para concretizar o trabalho sem depender de outros fora da equipa. O Dono do Produto o responsvel por maximizar o valor do produto e do trabalho da Equipa de Desenvolvimento e o nico com poderes de gesto sobre o Product Backlog8. As suas decises so visveis no contedo e na ordenao do Product Backlog. Ningum est autorizado a dizer Equipa de Desenvolvimento para trabalhar num conjunto diferente de requisitos, e a Equipa de Desenvolvimento no est autorizada a agir sobre o que qualquer outra pessoa disser.

Product Backlog - uma lista ordenada de tudo o que poder ser necessrio no produto e nica fonte de requisitos para quaisquer alteraes a serem feitas no produto (Schwaber & Sutherland, 2011, p. 12).

19

A Equipa de Desenvolvimento constituda por profissionais trabalham para entregar um potencial Incremento Concludo do Produto no final de cada Sprint9. A dimenso das equipas no deve ser menor que trs, porque diminui a interao e os ganhos de produtividade so menores, e no devem ser maiores que nove elementos, porque mais requer demasiada coordenao. O Mestre Scrum (Scrum Master) responsvel para que o Scrum seja compreendido e praticado, garantindo que a Equipa adere teoria, prtica e regras. E pela primeira vez, na definio de uma metodologia de desenvolvimento de software, aparece uma referncia ao papel da liderana: o Mestre Scrum o Lder-Servidor para a Equipa Scrum (Schwaber & Sutherland, 2011, p. 6). O raio de ao do Mestre Scrum no se restringe apenas sua equipa porque ele ajuda os que esto fora da Equipa Scrum a compreender quais das suas interaes com a Equipa Scrum so teis e quais no so. O Sprint o corao do Scrum e representa um perodo de tempo de um ms ou menos onde criado um potencial Incremento Concludo do produto. Durante o Sprint no so feitas alteraes que afetem o Objetivo do Sprint; a composio da Equipa de Desenvolvimento mantm-se constante; os objetivos de qualidade no diminuem; e o mbito pode ser clarificado e renegociado entre o Dono do Produto e a Equipa de Desenvolvimento enquanto mais coisas so aprendidas. Um Sprint pode ser cancelado se o Objetivo do Sprint tornarse obsoleto. A noo que uma equipa tem todas as competncias para realizar o trabalho mais a sugesto de que o seu tamanho varie entre trs e nove elementos, representam uma limitao da aplicabilidade do Scrum. No caso da ESI, estudado na parte prtica da tese, existem vrias equipas que controlam partes diferentes dos sistemas informticos do BES. So raros os desenvolvimentos em que no necessrio a participao de uma ou mais equipas para conseguir desenhar, criar e integrar todos os componentes necessrios para entregar o projeto que o cliente pretende. Ao no estar preparado para a colaborao entre equipas, por preferir equipas pequenas e por favorecer perodos de desenvolvimento sem alteraes de tarefas, o Scrum no est preparado ser aplicado num ambiente de desenvolvimento empresarial sofisticado (Schwaber & Sutherland, 2011 : 5-8).

5.2.2 Lean IT
Segundo Bell e Orzen (2011), o Lean IT muito mais que um conjunto de ferramentas e de prticas; uma transformao cultural e comportamental profunda que encoraja todos na organizao a pensar diferente sobre o papel da informao de qualidade na criao e entrega de valor para o cliente.

20

A definio de Lean IT segundo Stephen Ruffa (2011 : 14) mantm a mesma orientao, acrescentando ainda que tornar-se lean muito mais do que ser bem-sucedido no corte de custos dirios o alvo mais frequente desde tipo de ferramentas e prticas. Em vez disso, requer a construo de capacidades dinmicas que promovam a estabilidade e consistncia, mesmo no meio das condies incertas e em constante mudana de hoje, para que estes resultados sejam possveis. A implementao do Lean IT, segundo as definies apresentadas anteriormente, requer que toda a organizao esteja unida e alinhada no mesmo sentido. No entanto, as entrevistas realizadas durante a investigao de Stephen Ruffa identificaram que apesar da enorme popularidade do Lean entre os executivos e praticantes, existe uma diviso tremenda entre eles e os que esto na fora de trabalho e mesmo entre os gestores de nvel intermdio. Uma das razes para esta diviso est na ateno que colocada nas ferramentas e tcnicas individuais muitas vezes sem muito foco nos aspetos mais profundos e transformacionais que os mtodos Lean tinham a inteno de avanar. O resultado desta disparidade entre a realidade e a teoria a inconsistncia na implementao do Lean e um nvel elevado de frustrao (Ruffa, 2011 : 1 - 2). Para aumentar as probabilidades de sucesso de uma implementao do Lean numa organizao necessrio enfatizar os princpios sobre as ferramentas (Bell & Orzen, 2011). O Lean nasceu e tornou-se popular na Toyota, durante os anos 90, resultado do desempenho fenomenal da empresa (Jones & Roos, 1990). Um dos lderes que criou esta metodologia que ajudou no s a Toyota mas vrias empresas da indstria Japonesa, foi Edwards Deming (Noguchi, 1995). Deming (1986) publicou catorze princpios chave em que os gestores se deviam concentrar para transformarem as suas organizaes. 1. Criar consistncia de propsito direcionado para a melhoria do produto e servio, com o objetivo de se tornar competitivo, permanecer no negcio e para criar emprego. 2. Adoptar a nova filosofia. Ns estamos numa nova era econmica. A gesto do ocidente deve despertar para o desafio, deve aprender as suas responsabilidades, e entrar na liderana da mudana. 3. Terminar a dependncia na Inspeo para atingir qualidade. Eliminar a necessidade de Inspeo massiva criando qualidade no produto em primeiro lugar. 4. Terminar a prtica de premiar negcio baseado no preo. Em vez disso, minimizar o custo total. Avanar para um nico fornecedor para cada item, numa relao de lealdade e confiana de longo-termo. 21

5. Melhorar constantemente e para sempre o sistema de produo e servio, para melhorar a qualidade e produtividade, e consequentemente diminuir os custos constantemente. 6. Instituir o treino no trabalho. 7. Instituir liderana. O objetivo da superviso deve ser ajudar pessoas, mquinas e aparelhos a fazer um melhor trabalho. Superviso da gesto est a precisar de uma remodelao, tal como a superviso dos trabalhadores de produo. 8. Eliminar o medo, para que todos possam trabalhar eficazmente na empresa. 9. Remover barreiras entre departamentos. Pessoas na investigao, design, vendas, e produo devem trabalhar como uma equipa, para preverem problemas de produo e de utilizao que possam ser encontrados no produto ou servio. 10. Eliminar slogans, exortaes e alvos para a fora de trabalho a pedir zero defects e novos nveis de produtividade. Esse tipo de exortaes apenas cria relaes adversrias, como a maioria das causas de baixa qualidade e baixa produtividade pertencem ao sistema e por isso esto para alm do poder da fora de trabalho. 11. Eliminar os padres de trabalho (quotas) ao nvel da fbrica. Substituir por liderana. Eliminar gesto por objetivos. Eliminar gesto por nmeros e objetivos numricos. Em vez disso, substituir por liderana. 12. Remover barreiras que roubam o trabalhador hora do seu direito ao orgulho do profissionalismo. A responsabilidade dos supervisores deve ser alterada de apenas nmeros para qualidade. Remover barreiras que roubam s pessoas de gesto e de engenharia do seu direito ao orgulho do profissionalismo. Isto significa, inter alia, a abolio da classificao anual de mrito e gesto por objetivos. 13. Instituir um programa vigoroso de eduo e de melhoria pessoal. 14. Colocar toda a gente na empresa a trabalhar para concretizar a transformao. A transformao o trabalho de todos. Bell e Orzen (2011 : 18) ilustraram a pirmide que deve governar uma organizao Lean, sem cargos organizacionais, mas sim princpios:
Figura 8 - Os princpios Lean organizados numa pirmide

22

Fonte: Bell e Orzen (2011 : 18)

Em termos de pirmide de gesto, Bell e Orzen partilham da mesma viso de Ken Blanchard (Blanchard, Invert the Pyramid, 2008) quando promovem que a pirmide organizacional10 deve ser invertida (Bell & Orzen, 2011, p. 20).
Figura 9 - A pirmide organizacional invertida do Lean

Fonte: Bell e Orzen (2011 : 18)

Inverter a pirmide no quer dizer que os colaboradores passam a controlar ou a gerir a organizao. Por outro lado, os consumidores no interagem diretamente com os lderes empresariais nem sabem qual a Direo
A pirmide organizacional o nome comum que atribudo hierarquia tradicional de poder instituda nas organizaes
10

23

Estratgica que estes definiram para a empresa. O que os consumidores sabem quo bem so servidos pelos colaboradores da empresa. Por estarem a interagir diretamente com o consumidor, os colaboradores esto numa posio privilegiada para comunicar gesto formas de melhorar o servio prestado. A abordagem da inverso da pirmide pretende transmitir ainda que, tal como foi referido na Liderana Servidora, depois da Liderana definir a Direo Estratgica a pirmide deve inverter-se para que a funo do lder seja estar com os colaboradores de forma a perceber como melhorar, gerar ideias e garantir que eles tm tudo o que precisam para fazer o seu trabalho (Bell & Orzen, 2011 : 20). Um dos maiores erros que as empresas cometem ao implementarem o Lean focarem-se demasiado em reduzir custos (Bell & Orzen, 2011 : 143).

6 - Esboo das Hipteses em Investigao

As hipteses que vo ser investigadas so as seguintes: 1. A metodologia de desenvolvimento de software GEM contribuiu positivamente para o aumento de produtividade e competitividade da equipa de desenvolvimento dos Canais Diretos da ESI 2. A liderana usada na aplicao do GEM contribuiu para o crescimento dos colaboradores enquanto lderes

7 - Metodologia 7.1 - Enquadramento da Empresa

A Esprito Santo Informtica, ACE um agrupamento complementar de empresas que iniciou a sua atividade em 2006 com o objetivo de gerir os Sistemas de Informao pertencentes aos membros agrupados:

24

Figura 10 - Estrutura Empresarial da Esprito Santo Informtica

A ESI tem 5 direes, 65 ncleos e 530 pessoas onde 55% so colaboradores internos da empresa e 45% esto a trabalhar em regime de outsourcing. Esta investigao vai focar-se numa equipa designada por Canais Diretos, composta por 1 lder de equipa, 5 gestores, 1 arquiteto tcnico, 5 coordenadores tcnicos, 8 analistas aplicacionais, 5 analistas funcionais e 2 pessoas de apoio gesto. A metodologia de desenvolvimento de software GEM foi aplicada equipa tcnica mas o seu impacto estendeu-se aos Canais Diretos como um todo.

7.2 - Estratgia Metodolgica

A abordagem para a construo de teoria ser indutiva com propsito exploratrio e descritivo. A estratgia de investigao corresponde a um estudo de caso sobre a implementao de uma nova metodologia de desenvolvimento de software (GEM), na equipa de home-banking do BES, segundo um horizonte temporal transversal de 2 anos. A investigao vai usar os seguintes dados qualitativos e quantitativos: Anlise dos resultados dos projetos realizados pela equipa entre 2010 e 2011; o Nmero de projetos realizados o Dimenso dos projetos (em horas) o Dimenso da equipa o Nmero de projetos entregue on-time o Nmero de projetos entregue on-budget o Nmero de projetos entregue on-target Observao participante do investigador durante todo o processo de implementao e evoluo da metodologia; Anlise das respostas ao questionrio enviado a: o Equipa de desenvolvimento, o Equipa de gesto 25

o Administradores o Clientes do Software produzido

8 - Relevncia da Investigao
A relevncia desta investigao est diretamente relacionada com os pontos onde a metodologia de desenvolvimento de software GEM pretende superar as metodologias j existentes: As taxas de insucesso dos projetos de desenvolvimento de software provam que as metodologias atuais no esto a conseguir cumprir com o seu objetivo principal: fazer com que os projetos tenham sucesso; As metodologias de desenvolvimento de software atuais adicionam ineficincias nas equipas afectando a sua competitividade; O papel da liderana no crescimento e evoluo das equipas no explorado nas metodologias atuais; No contexto atual de globalizao e de elevada competitividade econmica essencial encontrar formas de ser mais eficiente e eficaz. O GEM uma forma de o fazer.

9 - ndice Geral (provisrio) da Investigao

Resumo Abstract Agradecimentos ndice Introduo Captulo 1 A liderana nas empresas Captulo 2 Metodologias de desenvolvimento de software Captulo 3 GEM: GoTo Evolution 2.1 2.2 2.3 2.4 2.5 2.6 O que o GEM Planeamento Desenvolvimento Controlo Avaliao Melhoria Contnua

Captulo 4 Metodologia de Investigao

26

4.1 ESI: a empresa 4.2 Canais Diretos: a equipa de desenvolvimento 4.3 Estratgica metodolgica 4.3.1 Dados Secundrios 4.3.1.1 Observao participante do investigador 4.3.1.2 Anlise do desempenho da equipa em 2010 e 2011 4.3.3 Dados Primrios 4.3.3.1 Questionrio enviado Equipa 4.3.3.2 Questionrio enviado aos clientes da equipa Captulo 5 Anlise dos resultados, interpretaes e desenvolvimentos futuros 5.1 Anlise, interpretao e consideraes sobre o desempenho da equipa 5.1.1 Ano 2010 5.1.2 Ano 2011 5.2 Anlise, interpretao e consideraes sobre o questionrio 5.2.1 Enviado equipa 5.2.2 Enviado aos clientes do trabalho da equipa 5.3 Desenvolvimentos futuros Concluses Referncias Bibliogrficas

27

10 - Bibliografia 10.1 Referncias Bibliogrficas

ANTOLIC, Z. (s.d.). An Example of Using Key Performance Indicators for Software Development Process Efficiency Evaluation. Zagreb: R&D Center. BASS, B. (1990). From transactional to transformational leadership: learning to share the vision. Organizational Dynamics, 18 (3). BELL, S., & ORZEN, M. (2011). Lean IT - Enabling and Sustaining Your Lean Transformation. New York: Taylor & Francis Group. BLANCHARD, K., & HERSEY, P. (1986). Psicologia para Administradores: a teoria e as tcnicas da liderana situacional. So Paulo: EPU. BLANCHARD, K., & HODGES, P. (2005). Lead like Jesus. Nashville: Thomas Nelson, Inc. BLANCHARD, K., & JOHNSON, S. (2003). The One Minute Manager. New York: HarperCollins Publishers Inc. BOEHM, B. (1998). A spiral model of software development and enhancement. TRW Defense Systems Group. BRIDGES, W. (1996). Leading the de-jobbed organization. In F. Hesselbein, M. Goldsmith, & R. Beckhard, The leader of the future (p. 17). San Francisco: Jossey-Bass. BRUMBACK, G. (1999). The power of servant leadership, 52 (3). Personal Psychology. BURNS, J. (1978). Leadership. New York: Harper & Row Publishers. CARLYLE, T. (2001). On Heroes, Hero-Worship, and The Heroic in History. Pennsylvania: The Pennsylvania State University. COCKBURN, A. (2000). Selecting a Projects Methodology. IEEE SOFTWARE, 65. COLLINS, J. (2001). Good to Great. New York: HarperCollins Publishers Inc. DEMING, E. (1986). Out of the Crisis. MIT Press. DRUCKER, P. (1964). Administrao lucrativa, 2ed. So Paulo: Pioneira. FREIXO, M. (2011). Metodologia Cientfica: Fundamentos Mtodos e Tcnicas. Lisboa: Instituto Piaget.

28

GARRISON, & KELLER. (2004). Southwest Airlines Case Study. Cincinnati: Thomas A. Hauck. GREENLEAF, R. (1991). The Servant as Leader. Indianapolis: The Robert K. Greenleaf Center. GUEVARA, J., HALL, L., & STEGMAN, E. (2010). IT Key Metrics Data 2011: Key Application Measures: Project Measures: Current Year. Gartner. HARTMANN, D., & DYMOND, R. (s.d.). Appropiate Agile Measurement: Using Metrics and Diagnostics to Deliver Business Value. JONES, D., & ROOS, D. (1990). The Machine That Changed the World. New York: Simon & Schuster Inc. KARLSTRM, D. (2004). Integrating Management and Engineering Processes in Software Product Development. Lund. KIRKPATRICK, S., & Locke, E. (1991). Leadership: do traits matter? Academy of Management Executive, Vol.5, n2. LEXICOTECA. (1985). Moderno Dicionrio da Lngua Portuguesa. Crculo de Leitores. NOGUCHI, J. (Dezembro de 1995). The Legacy of W. Edwards Deming. Quality Progress, 28 (12), pp. 35-37. QUAY, J. (1997). On becoming a servant leader, 9 (3). Journal of Management Consulting, 83. RAMSIN, R. (2006). The Engineering of an Object-Oriented Software Development Methodology. York: The University of York. ROYCE, W. (1970). Managing the Development of Large Software Systems. The Institute of Electrical and Electronics Engineers, Inc. ROYCE, W. (1998). Software Project Management - A Unified Approach. Addison-Wesley Longman. RUFFA, S. (2011). The going Lean fieldbook: a pratical guide to Lean transformation and sustainable success. New York: Lean Dynamics Research, LLC. SEZER, B. (2007). Software Engineering Process Improvement. Middle East Technical University. SGI (2001). The Standish Group Iinternational, Inc. EXTREME CHAOS. SGI (2009). The Standish Group International, Inc. CHAOS Summary 2009 The 10 Laws of Chaos. 29

10.2 Webgrafia
BECK, K., BEEDLE, M., BENNEKUM, A. v., COCKBURN, A., CUNNINGHAM, W., FOWLER, M., . . . THOMAS, D. (2001). Manifesto para o Desenvolvimento gil de Software. Obtido em 8 de Abril de 2012, de agilemanifesto.org: http://agilemanifesto.org/iso/ptpt/ BLANCHARD, K. (25 de Julho de 2008). Extra Minute Manager. Obtido em 8 de Abril de 2012, de YouTube: http://www.youtube.com/watch?v=JT6NLYcf7Ps BLANCHARD, K. (2008). Invert the Pyramid. Obtido em 10 de Abril de 2012, de Youtube: http://www.youtube.com/watch?v=id09a40EvBw BLANCHARD, K. (25 de Maio de 2010). Where The Action Is. Obtido em 8 de Abril de 2012, de YouTube: http://www.youtube.com/watch?v=B2xasutdbBo BLANCHARD, K., & BLANCHARD, S. (25 de Julho de 2008). Situational Leadership II. Obtido em 8 de Abril de 2012, de Youtube: http://www.youtube.com/watch?v=M1uyU3YSqes GONZAGA Mentor Gallery Clip. (25 de Maio de 2010). Where the Action Is. Obtido em 1 de Janeiro de 2012, de YouTube: http://www.youtube.com/watch?v=B2xasutdbBo SCHWABER, K., & SUTHERLAND, J. (Outubro de 2011). Guia Oficial do Scrum. Obtido em 8 de Abril de 2012, de scrum.org: http://www.scrum.org/storage/scrumguides/Scrum_Guide.pdf

10.2 A consultar
BUCHANAN, L. B. (1998). The Impact of Big Five Personality Characteristics on Group Cohesion and Creative Task Perfomance. Blacksburg, Virginia: Faculty of the Virginia Polytechnic Institute and State University. CHEN, J., DUGGER, J., & HAMMER, B. (2001). A Kaizen Based Approach for Cellular Manufacturing System Design: A Case Study. The Journal of Technology Studies. HERRE, C. (2010). Promoting team effectiveness: How leaders and learning processes influence team outcomes.

30

KRISHNA, Y. R. (2006). Effects of transformational leadership on team performance and commitment: Mediating role of psychological empowerment. PALMER, V. (2001). Inventory Management Kaizen. Proceedings of the 2nd International Workshop on Engineering Management for Applied Technology. PARIS, C. R., SALAS, E., & CANNON-BOWERS, J. A. (2000). Teamwork in multiperson systems: a review and analysis. ERGONOMICS, VOL. 43, N 8. QUIGLEY, N. R. (2003). The Relationship Between Leader Core SelfEvaluations, Team Feedback, Leader Efficacy, Transformational Leadership, Team Efficacy, Team Goals, Team Action and Transition Processes, and Team Performance. SCHILDERMAN, J. (2011). How can a team leader influence performance in a cross-functional team? The effects of diversity belief and conflict management. TURNER, J. R., & MLLER, R. (2005). The Project Manager's Leadership Style as a Success Factor on Projects: A Literature Review. Project Management Journal.

11 - Planeamento (Cronograma) da Investigao

12 - Orientador / Co-Orientador
Orientador: Professor Doutor Nuno Goulart Brando Co-Orientador: Professor Doutor Jos Lopes Costa 31