5. ANLISE CASO Claramente, neste caso, nenhuma das partes saiu um vencedor.

BBB Indstrias acabou com usurios insatisfeitos, desconfiana em sistemas de informao, atrasos, sistemas parciais, de baixa moral, e os principais problemas no resolvidos. Computao rpido acabou com significativas despesas unreimbursed, um pobre reputao no mercado de vendas de Sistemas de Informao, e alguns produtos inteis parciais. SW1 tambm acabou com unreimbursed despesas, e tambm uma reputao manchada no Vendas de Sistemas de Informao e as perspectivas pobres para o futuro negcios na comunidade rpido computador do usurio. Abaixo est uma anlise de como estes problemas podem ser atribuda a falta de capacidade de resposta Teoria W fundamentais princpio (Faa todos um vencedor) e para a subsidiria dois princpios (Ident @ e gerenciar seus riscos e plano de vo a & FRR do plano). A anlise indicou tambm maneiras em que o princpios poderiam ter sido utilizados para evitar os problemas e fazer os vencedores participantes. 5,1 fazer com que todos a Winner A principal fonte de dificuldade foi o contrato ganha-perde estabelecida entre BBB e Computao rpida: no pagamento BBB menos tudo o que pedido, no horrio (Seo 4.5). Computao rpido deveria ter feito uma mais completa anlise de seu potencial de superao (avaliao de risco), e um avaliao completa dos benefcios de entrar nas vendas Informaes de mercado do sistema. Se os benefcios eram altas o suficiente, que deveria ter se aproximado presidente MMM de autorizar seus gastos adicionais de dlares de lucro para cobrir os custos adicionais de desenvolvimento de software. Caso contrrio, eles devem ter caiu fora. Gerente Geral BBB deve ter ouvido o Sr. Smith adverte, e ou necessria uma mais detalhada e plano realista e estimativa de custo de computadores velozes, ou ido frente com Colossal. BBB poderia ter feito melhor win-win situao de no fornecimento do sistema de acoplamento e de transio para o Ano Novo em um momento em que os provveis horrios de desenvolvimento no foram bem conhecidos. Outra grande dificuldade foi o uso SWL do Sr. Holmes. Se SW1 seriamente queria penetrar os computadores velozes mercado, eles deveriam ter usado o Sr. Brown (Seo 4.6). Holmes no deveria ter aceito a responsabilidade de fazer pessoas vencedores at que compreenderam melhor a situao (seo 4.6). SW1 gesto deve ter feito mais para fazer Holmes um vencedor: informou-o dos riscos, feito um trabalho melhor de reconhecer seu bom trabalho em se Mdulo 1 execuo (Seo 4.8), e de monitorar o seu nvel de frustrao e probabilidade de deixar SW1 (seo 4.8). Como indicado na Seo 2, tornando vencedores pessoas envolve buscando dia-a-dia de conflitos e alter-los

em win-win situaes. Uma excelente oportunidade para fazer isso ocorreu no Design Review (Seo 4.6), quando SW1 recusou-se a produzir mais de quatro relatrios de vendas, e em produzir qualquer loja de departamento informa a todos. No entanto, o conflito no foi abordado, eo projeto continuou a inflar expectativas dos usurios, sem qualquer tentativa de obter SW1 para fornecer os recursos prometidos. Uma Teoria soluo W para este problema seria considerar o condies necessrias para tornar vencedores de cada um dos interessados partes: . BBB e seus clientes: Fornecer o mais importante relatos da entrega inicial, com os outros relatrios que logo que possvel. . SW 1: Fornecer um cronograma realista e oramento para produzindo os relatrios desejados (e outras capacidades). . Computao rpido: Desenvolver um sistema forte, com mais potencial de vendas, dentro de um oramento realista e acessvel e agendar. Posteriormente, uma anlise muito mais profunda seria feito para determinar oramento realista e estimativas de programao como funes da quantidade de funcionalidade a ser entregue em cada incremento. Estes nveis de funcionalidade, sua associados horrios, e definio de Computao Rpido de "acessibilidade" fornecer alguns graus de liberdade dentro do qual podem ser possvel definir uma soluo ganha-ganha, Se assim for, o projeto pode ir frente em tal base. Se no, o projeto deve ser dissolvida: todos no seria um vencedor, mas que seria minimizar suas perdas. Um problema do dia-a-dia semelhante, que foi adiada em vez do que foi abordado o Fast Computing problema pagamentos (Seo 4.8). Um problema relacionado foi a adio de mudanas e melhorias para o sistema sem alterar o oramento ou cronograma (Seo 4.7). Isso geralmente leva a um perde-perde situao em que o oramento e cronograma e dar todo o capacidades originais e novos no esto concludas. A W Teoria soluo envolveria priorizando as alteraes propostas respeitar as capacidades originais desejados, alocando o topo recursos prioritrios para as trs incrementos programados; ento definio de um incremento 4 e assegurando os usurios de que seus restantes funes que iria ser incorporado em Tncrement 4, se a gesto BBB concordou em fornecer ao oramento para eles. Alguns outros problemas foram criados, estabelecendo expectativas irrealistas. Emisso de Pedidos vagas para Proposta

(Seo 4.4) um exemplo clssico: os usurios tendem a interpretar a requisitos expansivo, enquanto os desenvolvedores de interpret-los austeramente, criando uma situao perde-perde inevitvel. O custo subestimado e interpretao de especificaes para o Sistema Financeiro outro exemplo (Seo 4.10). Por outro lado, alguns princpios Teoria W foram seguido bem. O BBB Gerente Geral da inicial conversa com o Sr. Smith (Seo 4.2) estabeleceu um clima realista de expectativas. A escolha de FGSM como o inicial do sistema para implementar (Seo 4.3) foi bom, uma vez que Gerentes FGSM foram campees do produto entusiasmados. Teve as outras situaes foram tratadas de forma semelhante, com a participantes esforando mais para acomodar os outros ' interesses, o projeto poderia ter tido uma boa chance de fazer os vencedores participantes. 5.2 Plano de Voo e da mosca do Plano Planejamento do projeto foi deficiente em relao ao importantes de software de planejamento de tcnicas de Desenvolvimento. Entre essas deficincias, podemos encontrar: uma total falta de Gerenciamento de Configurao, V & planejamento inadequado V, Incompletas Planos de reviso, nenhum controle dos problemas que foram levantados na Reviso de Requisitos. Algum nvel superior marcos foram estabelecidos, mas nenhuma tentativa foi feita para identificar dependncias e crtico-caminho itens. Mas o grande problema aqui era para colocar os planos em um realista base. Oramentos e horrios foram determinados mais de figuras alvo otimistas do que de qualquer justificativa com base em tcnicas de estimativa de custos e anlises de dependncia de tarefas. Assim, embora planos mais elaborados abordagem teria evitado alguns problemas, no teria curado o oramentocronograma de funcionalidade problemas de incompatibilidade. Por exemplo, SWL do projetado produtividade para o Fast O desenvolvimento do computador foi considerada como sendo igual a sua produtividade em projetos de computador Colossal. Mesmo uma spera anlise utilizando o modelo de custos COCOMO [2] indicou um fator de 3 provvel reduo na produtividade devido ao pessoal capacidade e experincia, a volatilidade sistema de apoio, reduzida ferramenta de apoio, e de compresso do cronograma. 5.3 Identificar e gerenciar seus riscos Em alguns casos, os participantes fizeram um bom trabalho de identificao e gesto de riscos. Em particular, o Sr. Smith recomendao na Seo 4.3 para iniciar e prosseguir uma desenvolvimento incremental foi muito bom. Mas houve muitas situaes em que a falta de gesto de riscos causados

problemas srios. Permitindo que duas semanas para se preparar para a RFP (Seo 4.4) reflete uma negligncia grave de gesto de risco. Geral BBB Gerente deve ter feito uma anlise de risco de aquecimento Sr. Necessidade Smith Computing Avaliao Rpida para "esforo extraordinrio" para ter sucesso (Seo 4.5), em particular para realizar uma estimativa independente do custo de desenvolvimento e programao. BBB tambm fez nenhuma avaliao de risco, olhando por trs da interface entre computao rpida e SWL. Eles no se investigar se SW1 usaria o Sr. Brown no seu trabalho, e foram pegos de surpresa quando SW1 atribudo ao desconhecido Sr. Holmes. Holmes se fez uma anlise muito pouco do riscos que ele estava se metendo. BBB no avaliar o risco de o altamente otimista, cronograma de desenvolvimento altamente sobrepostos incrementais proposto por SW1 (Tabela 5, a seco 4.7). Eles eram muito preocupado com o estabelecimento de um cronograma ambicioso para Incrementar uma para atender o prazo final de Ano Novo. Tal incrementos de sobreposio so as principais fontes de risco, como as mudanas em incrementos anteriores costumam ter efeitos graves sobre ondulao os incrementos posteriores em desenvolvimento. Em um caso, a preveno de riscos causou um todo "um problema vencedor ". Mr. Smith identificou vrios riscos devido falta de compromisso da gesto de usurio, e dirigida por estes um grande esforo para vender os usurios sobre as vantagens de tecnologia da informao. Este saiu pela culatra quando os usurios compararam suas expectativas irreais para os resultados do projeto. A soluo preferida Teoria W seria benefcio do usurio sof projees mais realista em termos de expectativa de curto prazo e benefcios de longo prazo, e para envolver os usurios mais de perto na anlise e preparao para os benefcios.