JA

Projetos de software não precisam se atrasar, dispendiosos e irrelevantes

Artigo 12 MIN read

Tecla toca

Com muita frequência, os projetos de TI não conseguem cumprir seu hype. Por que continua acontecendo-e como pode ser corrigido? cronogramas irrealistas; e recursos insuficientes. Salvo para
  • In a BCG survey of global C-suite executives, nearly half of all respondents said that more than 30% of their organization’s technology development projects were over budget and late.
  • Reasons for IT failures included a lack of alignment between the technology and business sides of the organization about operational objectives; unrealistic timelines; and insufficient resources.
  • Better IT outcomes depend on a strategic partnership between IT and the business side, incentives for meeting specific benchmarks, carefully designed performance tracking mechanisms, and a suitable talent pool.
Saved To Meu conteúdo salvo
Download Artigo

Tornou -se uma das queixas mais persistentes e inabaláveis ​​das empresas grandes e pequenas: projetos de tecnologia sofrem rotineiramente atrasos de desenvolvimento e excedentes de custos caros, fazendo com que eles apareçam em muitos casos que são mais problemáticos do que valem a pena. Os problemas continuam surgindo e quais podem ser as soluções mais eficazes. Descobrimos que os princípios populares de desenvolvimento de software ágil-envolvendo, por exemplo, a equipe interdisciplinar e o rastreamento de progresso-são pertinentes, mas não suficientes para garantir o sucesso. Também aprendemos que melhorar os resultados dos projetos de TI na maioria das empresas dependerá diretamente da liderança tecnológica, criando os requisitos e a cultura adequados para que as equipes sejam capazes de entregar de maneira ágil. Até agora, isso provou ser difícil de alcançar.

Having heard these complaints too frequently to ignore, we set out to determine if the anecdotal claims are true—and, if they are, to identify why these problems keep arising and what the most effective solutions might be.

What we learned was surprising, both in terms of the breadth of project shortfalls and the way they must be addressed. We discovered that popular agile software development principles—involving, for instance, cross-disciplinary teaming and progress tracking—are pertinent but not sufficient to guarantee success. We also learned that improving the outcomes of IT projects at most companies will depend squarely on technology leadership creating the proper requirements and culture for teams to be able to deliver in agile fashion. Up to now, this has proved to be difficult to achieve.

IT Frustrations Are Palpable

To begin tackling this issue, BCG conducted a survey of global business and technical-side C-suite executives across 25 industries, including Tecnologia , bens de consumo, varejo, assistência médica e fabricação, entre muitos outros. E evitamos implementações de planejamento de recursos corporativos em larga escala ou migrações em nuvem e outros grandes projetos potencialmente impactados pelas contribuições de contratados externos e integradores de sistemas; Tais projetos são tão amplos e complexos que seria difícil determinar o local preciso de suas deficiências. Quase metade de todos os entrevistados disse que mais de 30% dos projetos de desenvolvimento de tecnologia em suas organizações sofrem de atrasos ou excedentes de orçamento, enquanto quase um em cada cinco entrevistados indicou que menos do que os resultados satisfatórios ocorrem mais de 50% das vezes. (Consulte o Anexo 1.)

We deliberately focused our survey on internal software development projects, primarily custom programs and applications targeting a specific business priority, such as marketing automation and streamlining tools, forecasting suites, and pricing models. And we avoided large-scale enterprise resource planning implementations or cloud migrations and other big projects potentially impacted by the contributions of external contractors and system integrators; such projects are so wide ranging and complex that it would be difficult to determine the precise locus of their shortcomings.

The survey results were unambiguous: disappointment with IT is a real thing. Nearly half of all respondents said that more than 30% of the technology development projects in their organizations suffer from delays or budget overruns, while nearly one in five respondents indicated that less than satisfactory outcomes occur more than 50% of the time. (See Exhibit 1.)

Moreover, despite the hype in recent years that agile software is an antidote to failing IT projects, our survey found that there was no correlation between the methodology used to design and deliver programs and their success. Obviously, there are exceptions to this—agile principles can underpin excellent outcomes. But not consistently. In fact, 64% of respondents said their IT teams already used some version of agile software development tools as the basis for their primary program design efforts. And still the troubling trend lines for IT projects have continued.

The executives who took BCG’s survey also had definite ideas about why the scheduling and budget overruns were so commonplace. Three causes stood out as the worst culprits: lack of alignment between the technology and business sides of the organization regarding the specific operational objectives for the program; unrealistic timelines; and insufficient financial and developer resources earmarked for the project. (See Exhibit 2.)

Taken together, these three explanations for why IT projects languish point to organizational leadership problems on both the technology and business sides of a company. CIOs, CTOs, and the heads of IT departments (or whatever their title is at a given company) are all too often either left out of the overall decision-making process when a technology implementation is initiated, or they fail to plainly set expectations for what an investment in a new application will specifically deliver both in terms of a timeline and performance. Ultimately, overcoming this leadership challenge is the biggest driver of success.

It is worth noting, however, that technology leaders at companies have significant challenges to navigate to make the types of changes required to get IT projects back on track. CIOs and CTOs are compelled to oversee work on disciplines much broader than their skillsets as organizational managers, for instance; engineering decisions are complex and usually beyond a technology leader’s knowledge set.

Ao mesmo tempo, os líderes empresariais não entendem completamente o portfólio de um CIO, especialmente suas nuances técnicas. Como resultado, os CIOs são responsabilizados e penalizados por qualquer obstáculo e defeito técnicos, mas geralmente não são recompensados ​​quando entregam para planejar ou além das expectativas. Apesar dessas questões, os líderes de tecnologia não têm escolha a não ser adotar novas abordagens para melhorar os resultados de TI - porque a situação atual não é sustentável. O primeiro é uma visão de 30.000 pés e apenas reflete que algo está genericamente errado; Este último deve ocorrer em um nível mais granular, onde os problemas são resolvidos. Para adotar essa abordagem mais granular, é essencial explorar os elementos comuns presentes quando um projeto de TI é bem -sucedido - e considerar quais novas abordagens são necessárias para adotar essas práticas mais salientes.

Overcoming the Disappointments

Of course, identifying that a leadership problem exists and alleviating it are two very different things. The former is a 30,000-foot view and just reflects that something is generically wrong; the latter must occur at a more granular level, where the problems are addressed. To take that more granular approach, it is essential to explore the common elements that are present when an IT project succeeds—and to consider what new approaches are necessary to adopt these more salient practices.

Based on survey responses, we determined that generating better IT outcomes depends on the following factors.

A Strategic Partnership. Este é o assento proverbial na mesa. Quando os líderes de tecnologia estavam diretamente envolvidos desde o início no desenvolvimento da estratégia para uma construção de tecnologia, a taxa de sucesso foi 154% maior que os projetos sem esse canal de comunicação. Os líderes de tecnologia falam um idioma muito diferente dos gerentes de departamento de negócios, que não podem avaliar paradigmas e arquétos técnicos ou algoritmos de AI e dicionários de aprendizado de máquina. Mas esses gerentes devem ser capazes de descrever adequadamente quais melhorias de desempenho estão buscando em um novo aplicativo ou programa e o que constitui um retorno positivo do investimento. Em outras palavras, o diálogo estratégico entre os usuários e os construtores deve ser o primeiro passo, em vez de envolvê -lo em uma segunda etapa ao se comunicar no mesmo idioma, se torna muito mais difícil, se não impossível.

In turn, CIOs must take the business wish list and explain what is possible—and what resources are required to achieve the possible—in clear language that demystifies the technology. In other words, the strategic dialogue between the users and the builders should be the first step, rather than engaging IT in a second step when communicating in the same language becomes much more difficult, if not impossible.

incentivos. Na maioria das empresas, os desenvolvedores e designers de tecnologia estão presos em um ciclo de feedback negativo, no qual os resultados mínimos são resultados aceitáveis, enquanto o valor real traz pouco aviso e certamente o mínimo de ganho profissional. A mera proficiência técnica - sem ganhos mensuráveis ​​reais, por exemplo, datas ou custos de entrega - é considerado o padrão que atende às expectativas. Erros, erros, bugs e atrasos que podem resultar de riscos para melhorar o processo de design e desenvolvimento na construção de um aplicativo são penalizados. Com o teto de cabeça e o risco negativo, manter o status quo é uma opção mais sustentável para os desenvolvedores. Por exemplo, meça o sucesso de um projeto de TI em velocidade ao resultado; A entrega desejada pode ser que um programa de preços cubra primeiro um subconjunto de categorias relativamente pequeno e depois amplie um grupo mais amplo na próxima iteração e, em seguida, adiciona decisões de remarca em mais uma versão, e assim por diante, à medida que evolui. Três métricas críticas de melhoria de desenvolvimento de software se destacaram como tendo o potencial de motivar os melhores resultados:

A better approach is to incentivize incremental gains that can ultimately provide significant returns to the organization. For example, measure the success of an IT project in speed to outcome; the desired delivery could be that a pricing program first covers a relatively small subset of categories, then broadens to a wider group in the next iteration and then adds markdown decisions in yet another version, and so on as it evolves.

The power of incentives is supported strongly by the BCG survey. Three critical software development improvement metrics stood out as having the potential to motivate the best results:

When meaningful rewards were offered for improvements in all these dimensions, the success rate for IT efforts were nearly 25% higher than for projects without such incentives.

Performance Tracking. Simply put, technology teams are frequently not focused on business outcomes. Engaged—and, in our view, distracted—by concentrating keenly on how a program is built, developers view success in terms of achieving steps or technology benchmarks, not in company results. The problem lies in not establishing benchmarks in the form of KPIs, which typically gauge business in numerical scores that can be tangibly and objectively measured and analyzed.

For instance, commonly program developers will set as their goal to build a data layer, or install a CRM program, or design an API layer. But for successful technology projects, these goals should be reframed as creating a common data layer around transactions for the past five years that can serve as the foundation of business intelligence and analytics efforts, directly informing strategic aims.

Da mesma forma, a implantação de um CRM é um alvo menos útil do que implementar uma nova campanha de marketing na metade do tempo que levou antes. E projetar uma camada de API pode ser melhor traduzida como criação de uma ferramenta para refrescar imagens de produtos personalizados em um aplicativo essencial sem latência.

Too often, developers view success in terms of achieving steps or technology benchmarks, not in company results.

Depois que esses objetivos são cuidadosamente escolhidos e encobertos no idioma dos resultados dos negócios, é fundamental rastreá -los corretamente. Assim como em qualquer KPIs, se não forem medidos de maneira disciplinada e cuidadosamente calibrada, eles não terão um objetivo útil. Além disso, embora atingir os resultados dos negócios continue sendo uma meta essencial para uma implementação de tecnologia, as chances de resultados satisfatórias são aprimoradas ao agendar e o progresso do orçamento são rastreados e, se necessário, também vomitam no caminho. Especificamente, descobrimos que, quando os sistemas de alerta precoce eficazes estão em vigor - aqueles que podem alertar o gerenciamento dos problemas antes que se tornem muito pesados ​​- as taxas de sucesso aumentam em até 16 pontos percentuais. Em termos relativos, se o padrão-ouro é que um programa de tecnologia custa US $ 10 para entregar US $ 100 em doze meses, um atraso de seis meses normalmente significa mais custo e realização de valor adiada-e o retorno de 10x projetado é rapidamente reduzido para 4x ou 5x de vendência em valor atualizado. hoje. A variabilidade e as surpresas ocultas nas implementações técnicas são a norma, não a exceção. As soluções de TI em camadas, iterativas e dispersas de TI significam que pivôs e dependências peculiares durante qualquer projeto são um recurso, não um bug. Comcomcomsive a imprevisibilidade em uma equipe de TI pode produzir retornos decrescentes rapidamente. Na maioria dos casos, os gerentes de tecnologia são removidos por muitos anos a partir de design, desenvolvimento e programação reais. Consequentemente, a direção do dia-a-dia de um novo projeto usando as mais recentes ferramentas e plataformas de implementação não é necessariamente um ponto ideal do CIOS. Em vez disso, eles precisam confiar fortemente em suas equipes para serem criativas e inovadoras, usando suas experiências mais recentes como guias. A excelência em execução está nas mãos dos desenvolvedores. Primeiro de tudo, as equipes totalmente compensadas com recursos interdisciplinares tiveram um aumento de 76% no desempenho do projeto versus a organização que teve posições múltiplas e principais vagas. E a presença de engenheiros especializados que são especialistas em métodos de design e aprendizado de máquina em larga escala-entre os conjuntos de conhecimento mais atuais necessários em projetos avançados de TI em negócios-melhoraram os resultados em 14%. (Consulte Anexo 3.)

In our survey, we found that if reasonably valid tracking mechanisms are in place for an IT project, success rates improve. Moreover, while achieving business outcomes remains an essential goal for a technology implementation, chances for satisfactory outcomes are improved when scheduling and budgeting progress are tracked and, if needed, set back on course as well. Specifically, we found that when effective early warning systems are in place—those that can alert management of problems before they become too cumbersome—success rates increase by up to 16 percentage points.

Even when organizations have tracking mechanisms in place, however, the real financial impact of overruns is often understated. In relative terms, if the gold standard is that a tech program costs $10 to deliver $100 in twelve months, then a six-month delay typically means more cost and postponed value realization—and the projected 10x return is quickly reduced to 4x or 5x in actualized value.

Talent. Having the appropriate skills and capabilities in a technology organization to drive business performance improvements is one of the more difficult challenges today. Variability and hidden surprises in technical implementations are the norm, not the exception. The layered, iterative, and scattered nature of IT solutions means that pivots and quirky dependencies during any project are a feature, not a bug. Overcompensating for unpredictability in an IT team can produce diminishing returns quickly.

Consequently, the most impactful members in an IT organization are those with prior experience—the more experience, the better.

For CIOs and other technology leaders, there are serious obstacles to managing the talent pools required to drive successful IT implementations. In most cases, technology managers are removed by many years from actual design, development, and programming. Consequently, on-the-ground, day-to-day direction of a new project using the latest implementation tools and platforms is not necessarily a CIOs sweet spot. Instead, they have to rely heavily on their staffs to be creative and innovative, using their most recent experiences as their guides.

In other words, leadership in this instance is more about strategic management and keeping the project focused on the business outcomes than actual coding and cadences. Execution excellence is in the hands of developers.

The positive delta of well-travelled and well-rounded technical staffers manifested clearly in the survey when we looked closely at the connection between the type of talent companies had and IT project success rates. First of all, broadly, fully staffed teams with cross-disciplinary capabilities had a 76% increase in project performance versus organization that had multiple and key positions vacant.

But on a more granular level, having product managers with wide ranging skills increased success rates by 30%. And the presence of specialized engineers who are experts in large-scale design and machine learning methods—among the most current sets of knowledge needed in business-based advanced IT projects—improved outcomes by 14%. (See Exhibit 3.)

Ao considerar as razões comuns para o sucesso do desenvolvimento de software hoje, é difícil ignorar uma presença recente muito grande no ambiente de TI: o que é o que é o que é o que é o que é o que é o que é o que é o que é o que é o que é o que é o que é o que é o que é o que é o que é o que é o que é que o que é o que é que o que é o que é que o que é o que é que o que é o que é que o que é o que há de um pouco de que é uma presença recente e que é que a tecnologia de que é uma pessoa que se aproxima. que Genai apenas ampliará os princípios críticos para o sucesso que identificamos. Isso ocorre principalmente porque optar por adotar uma plataforma Genai está um passo intimamente ligado à agenda estratégica geral de uma empresa. A implementação da Genai exigirá uma profunda coordenação entre as contrapartes tecnológicas e de negócios, uma orientação inabalável para o valor comercial mensurável e um conjunto de incentivos atenciosos para atrair e recompensar talentos especializados que podem ser adquiridos nas nuances da inovação da IA ​​e de suas aplicações práticas.

We believe that GenAI will only amplify the critical principles for success that we have identified. This is primarily because choosing to adopt a GenAI platform is a step closely linked to a company’s overall strategic agenda. Implementing GenAI will require deep coordination between tech and business counterparts, an unwavering orientation towards measurable business value, and a set of thoughtful incentives to attract and reward specialized talent that can straddle the nuances of AI innovation and its hands-on applications.

PRÁTICOS PRÓXIMOS PASSOS

Cada um dos fatores descritos acima são essenciais para melhorar os programas internos de desenvolvimento de software e superar a noção de que os projetos falham com muita frequência. Tomados sozinhos, no entanto, esses fatores são apenas uma banda auxiliar, não uma cura; Tomados em conjunto, resultados reais são possíveis. Mais importante ainda, os elementos comuns do sucesso nas implementações de TI são diretamente o resultado de ações que CIOs e líderes de tecnologia estão na melhor posição de administrar em suas organizações. caixa de tempo. Isso pode envolver consultas com unidades de negócios que usarão o programa, juntamente com a pesquisa de mercado e a criação de protótipos. Mas deve se concentrar nos resultados específicos de curto prazo vinculados aos ajustes iterativos de longo prazo, que por sua vez evitam exercícios e uma análise excessiva. É importante ressaltar que a eficiência do estágio de descoberta é, de várias maneiras, uma função de quanta experiência a equipe de desenvolvimento tem-se eles já o viram antes, é mais provável que saibam como enfrentar um desafio no escopo sem demora. De fato, é aqui que o acesso aos melhores talentos é mais importante. Isso deve ser um objetivo definido como uma capacidade, não uma ferramenta ou uma especificação técnica. Por exemplo, o resultado potencial pode ser descrito como decisões de precificação em tempo quase real para uma região específica. Depois de provar em sua primeira implementação, ele pode ser expandido para mais regiões e um conjunto mais amplo de SKUs. Dessa forma, os negócios podem medir os resultados acionáveis ​​em um clipe rápido e fornecer feedback antes do desenvolvimento adicional. Para fazer isso, medir e recompensar a velocidade dos resultados e a extensibilidade de soluções, como a modularidade ou a capacidade de reutilizar aspectos do programa. Por sua vez, isso cria um desafio técnico enriquecedor para desenvolver rapidamente programas em uma linha do tempo estreita que é suficientemente flexível para ser aumentada e transferida para outras partes da organização. A melhoria dependerá da mudança de negócios como de costume, e os líderes de tecnologia estão na vanguarda dessa mudança. Ao fazer isso, os líderes de tecnologia podem garantir que os princípios ágeis, na verdade-finalmente-trabalhem. Inscreva -se

First, frame the parameters of the initial discovery-stage exercises—the phase where the project's goals, requirements, and scope are thoroughly examined—so that they are reasonably (and rigorously) time-boxed. This may involve consultations with business units that will use the program, along with market research and the creation of prototypes. But it should be focused on short-term specific outcomes tied to iterative long-term adjustments, which in turn avoids lengthy exercises and overanalysis.

The fastest path to placing the software in users’ hands is the quickest route to real-world value creation, rather than theoretical problem resolution. Importantly, discovery-stage efficiency is in many ways a function of how much experience the development team has—if they have seen it before, they are more likely to know how to address a challenge in scoping without delay. Indeed, this is where access to the best talent matters most.

Second, play an active role in identifying the core business outcome of the IT project—one tied to actual hands-on usage. This should be a goal defined as a capability, not a tool or a technical specification. For instance, the potential outcome may be described as pricing decisions in near-real time for a specific region.

Our empirical finding is that the initial design and production should be limited to what is possible to launch in three to four months of development work—and thus the program should be relatively circumscribed. After it proves out in its first implementation, it can be expanded to more regions and a broader set of SKUs. This way, the business could measure actionable outcomes at a fast clip and provide feedback ahead of further development.

Third, change the culture of IT development from a risk-averse mindset to taking chances to improve based on prior knowledge. To do this, measure and reward velocity of outcomes and extensibility of solutions, such as the modularity or the ability to reuse aspects of the program. In turn, that creates an enriching technical challenge to rapidly develop programs in a narrow timeline that are ultimately sufficiently flexible to be augmented and transferred to other parts of the organization.


Driving IT programs that support value creation without delays or budget overruns may seem like a tall task, but it is achievable. Improvement will depend on changing business as usual, and technology leaders are at the forefront of that change.

Technology leaders must enable the prerequisites for agile methodologies—implementing a culture change, hiring the appropriate talent, and creating an incentive structure that allows IT designer and developer teams to focus on salient outcomes, program expandability, and high throughput. By doing this, tech leaders can ensure that agile principles actually—finally—work.

Subscribe to our Digital, Technology, and Data E-Alert.

Autores

Diretor Gerente e Parceiro Sênior

Silvio Palumbo

Diretor Gerente e Parceiro Sênior
Nova Iorque

Diretor Gerente e Parceiro Sênior

Benjamin Rehberg

Diretor Gerente e Parceiro Sênior
Nova Iorque

Cientista de dados principal

Haoran Li

Cientista de dados principal
Nova Iorque

Conteúdo relacionado

Salvo para Meu conteúdo salvo
Download Artigo
= Salvo para Meu conteúdo salvo
Download Artigo