Fabio Turel

It’s easy to assume that since IT exists to support the business, the IT strategy should simply mirror or follow the business strategy.

This belief is not only misguided but can lead to operational inefficiencies, missed opportunities, and increased risk. In today’s digital-first world, every business, regardless of industry, needs a well-defined IT strategy that aligns with, but is not simply an accessory to, its business strategy.

IT Strategy: more than just a subset of Business Strategy

While business strategy does dictate the overarching direction and objectives that IT must support, an IT strategy is not something that can be derived purely from business goals.

Why?

Because IT operates under its own unique constraints and influences.

The role of IT strategy is not to duplicate or simply support the business strategy, but to reconcile the differences between the two. While business strategy might focus on growing market share, entering new markets, or enhancing customer experience, IT must deal with the technical reality of the need to regularly update systems, perform ongoing maintenance, address cybersecurity risks, and keep track of evolving technologies.

A well-crafted IT strategy acknowledges the limitations imposed by past decisions while also creating a roadmap for future flexibility. It allows companies to navigate technological debt, regulatory changes, and innovation cycles—all while supporting the company’s broader business goals.

Managing unique constraints

IT operates within its own set of constraints that may not always align perfectly with business strategy. These include:

• • Lifecycle management of legacy systems
  • Emerging technology trends
  • Industry standards and best practices
  • Regulatory requirements
  • Historical technology decisions

Reconciling Divergences

The IT strategy serves as a crucial bridge, reconciling any divergences between business needs and technological realities. It helps navigate the complex landscape of technological change while maintaining focus on business objectives.

Proactive planning

A well-crafted IT strategy allows organizations to proactively plan for technological advancements, rather than reactively responding to changes. This approach can lead to competitive advantages and improved operational efficiency.

Risk management

By addressing IT-specific challenges and opportunities, a dedicated IT strategy helps mitigate risks associated with technology investments, cybersecurity threats, and digital transformation initiatives.

The Cost of Ignoring IT Strategy

When businesses assume that they don't need an IT strategy because they aren't a technology company, they expose themselves to serious risks. Without an IT strategy, the organization may find itself trapped in a cycle of reactive problem-solving, leading to ballooning technical debt, inefficient processes, and missed opportunities for innovation.

Moreover, the absence of a structured IT strategy increases the likelihood of compliance issues as regulatory requirements become more complex and technology-driven. Today, even traditionally non-tech sectors like finance, healthcare, and manufacturing are deeply reliant on technology. Regulatory frameworks, such as the upcoming EU Digital Operational Resilience Act (DORA), emphasize the importance of operational resilience in technology, further highlighting why a strong IT strategy is crucial for long-term success.

Every Company is a Tech Company

In an era where technology underpins almost every aspect of business operations, saying, "We don’t need an IT strategy because we’re not a tech company," is akin to saying, "We don’t need a business strategy because we’re not a Fortune 500 company."

Regardless of industry, your business depends on technology to operate, and that requires a clear, cohesive IT strategy.

As artificial intelligence (AI) revolutionizes industries and daily life, its environmental footprint has become a pressing concern.

While AI holds promise for addressing environmental challenges, it simultaneously poses a significant threat due to its massive energy consumption and the acceleration in generating e-waste. This paradox presents a complex challenge for companies integrating AI into their IT strategies.

Similarly, MIT's AI Risk Repository identifies “Environmental Harm” as one of the major risks posed by AI, warning that unchecked growth in AI technologies could exacerbate existing environmental issues, such as climate change and resource depletion.

The Environmental Risks of AI

AI's energy demands are particularly alarming. Training and maintaining large AI models require vast amounts of computational power, which in turn draws heavily on electricity. The usage of ChatGPT, answering hundreds of millions of daily queries, can cost around 1 GWh each day, which is the equivalent of the daily energy consumption for about 33000 U.S. households.

Furthermore, the upkeep of AI systems, which requires frequent updates and new hardware, leads to the generation of significant amounts of e-waste. Without proper disposal or recycling, this e-waste can release toxic chemicals into the environment, harming ecosystems and human health.

Last but not least, the increasing demand for AI-related computing power puts additional strain on global energy infrastructure.

The role of IT Strategy

For IT strategy managers, addressing these challenges is crucial but complex. The lack of transparency from major AI companies regarding their emissions complicates immediate action: this opacity makes it difficult for organizations to quantify and address their environmental impact.

However, IT strategy is inherently forward-looking, requiring a long-term vision to guide present decisions. By formulating clear objectives and roadmaps, organizations can begin to manage AI's environmental footprint while aligning with sustainability goals.

Assess the environmental impact

Begin with a comprehensive evaluation of how AI adoption affects your organization's environmental footprint. Understanding current and future energy consumption and e-waste generation can help identify areas for improvement and sustainability optimization.

Integrate environmental criteria into decision-making

Embed environmental considerations into all strategic decisions related to AI. Whether it's evaluating new AI investments or planning deployments, every initiative should be scrutinized for its potential environmental impact. Engage stakeholders across departments to raise awareness and promote sustainability in AI development, deployment, and maintenance.

Set environmental KPIs

Define Key Performance Indicators (KPIs) that measure environmental performance across the organization at the level of the IT strategy, not limited to single initiatives. By regularly measuring the evolution of these KPIs, organizations can track the overall environmental impact of AI integration, aligning with broader sustainability goals.

Adopt a lifecycle perspective to limit e-waste

In addition to responsible e-waste management, IT strategy managers should adopt a lifecycle perspective for AI technologies. This means considering the environmental impact at every stage—from development and deployment to maintenance and disposal. By assessing the full lifecycle of AI systems, organizations can make more sustainable choices that align with both technological needs and environmental goals.

Conclusion

AI has the potential to play a positive role in addressing the environmental crisis, but only if its own environmental risks are managed effectively. As energy consumption and e-waste from AI technologies continue to rise, organizations cannot afford to ignore these issues.

While transparency from AI providers is still lacking, IT strategy managers can start laying the groundwork for long-term sustainability. By integrating environmental considerations into their strategic frameworks, organizations can turn the challenge of AI's environmental impact into an opportunity for innovation.

IT strategy is a marathon, not a sprint, and the road ahead requires developing a clear vision for sustainability that accounts for the unseen risks of today's technologies.

This proactive stance not only mitigates risks but positions companies as leaders in sustainable technology adoption. As the AI landscape evolves, so too must our strategies.

Project management fundamentally aims to achieve specific goals, but it inherently involves following a structured process to reach those goals effectively and efficiently.

This dual focus highlights the different skill sets that a project manager must possess, as the relationship between achieving a goal and following a process is complementary.

Achieving a Goal

The primary purpose of project management is to complete projects with specific objectives. These goals can vary widely, including launching a new product, constructing a building, implementing a new business service, or organizing a major event. A project's success is often measured by how well it meets these goals, delivers value to stakeholders, and adheres to constraints of time, budget, and quality.

Following a Process

Project management methodologies provide a structured process that guides the project manager through various stages of the project. This encapsulation of project work (which, due to the one-time nature of projects, does not belong to ongoing operational processes) is organized into distinct phases and knowledge areas, such as financial management and risk management.

The interplay between these two aspects can be summarized as follows:

1. Process as a means to an end

The structured process in project management is not a goal in itself but a means to achieve project goals. Without following a disciplined process, projects are more likely to exceed budgets, overrun timelines, fall short of quality standards, or fail altogether.

2. Adaptability and flexibility

Effective project management also involves adapting the process to better meet project goals as necessary. While the process provides a guide, it must remain flexible to accommodate changes and unexpected developments that can impact project outcomes.

3. Continuous improvement

Following a process facilitates continuous improvement. Lessons learned from the monitoring and controlling phases can be applied to future projects, enhancing the process itself and increasing the chances of success in achieving project goals.

4. Tailoring methodology to organizational needs

Effective project management requires adapting the methodology to align with the unique culture, operational practices, and strategic goals of the organization. Organizations may prioritize different aspects such as speed, quality, cost-efficiency, or innovation. Therefore, project management methodologies should be customized to fit the specific context of the project and the organizational environment. This customization ensures that the process not only supports achieving the project goals but also complements the existing workflows, resource capabilities, and risk tolerance of the organization.

How does Agile relate to this?

Agile project management introduces a distinct approach to achieving project goals through a repetitive, iterative process. Each iteration or "sprint" typically lasts a few weeks and aims to deliver a functional, incremental result. This methodology is characterized by its emphasis on adaptability, customer collaboration, and responsiveness to change. Unlike traditional project management, which follows a linear and sequential approach, Agile breaks down the project into manageable units allowing for frequent reassessment and adaptation of plans.

Conclusion

While project management is ultimately about achieving specific, targeted outcomes, the processes used are crucial for organizing efforts, minimizing risks, maximizing efficiency, and ensuring that the goals are met effectively. Thus, project management can be seen as goal-oriented but facilitated by a rigorous and adaptable process.

In order to shine, a hero needs a dragon to slay.

Similarly, Agile methodology is often explained by contrasting it with the rigidity of the Waterfall model.

What is Waterfall, exactly?

The Waterfall model is a process for Systems Development Life Cycle, focused on project management and solution design. It is characterized by highly planned, specification-driven development.

As possibly the first formalized model of this kind, Waterfall significantly influenced subsequent software development methodologies.

Waterfall is conventionally portrayed as a rigid, linear process with isolated phases. It is typically criticized for minimal or no involvement of stakeholders after the requirements phase, and a lack of flexibility in adapting to changing requirements.

Historic perspective

Several historical factors contributed to shaping "Waterfall" into what it was.

• Early computing limitations: during the 1950s and 1960s, computing was limited to mainframes with capabilities far below today's standards.

• Lack of modern development tools: functionalities such as code-highlighting, IDEs, and version control systems were not even thinkable at a time when input and output happened on a paper-based interface.

• Cost of computing resources: in the mid-20th century, computing resources were exceedingly expensive compared to labour costs, leading to a preference for manual analysis and testing, and minimized computing time.

• Complexity of projects: computing resources were uncommon, and therefore reserved to large projects, colossal in scale and complexity, and therefore necessitating meticulous coordination.

Considering these factors, it is clearly important for a development model to have maximum consideration for the use of computing resources, and anticipate the resolution of errors as much as possible.

Origins of the Waterfall inefficiency myth

The Waterfall model is commonly attributed to Herbert D. Bennington's 1956 paper and Winston W. Royce's 1970 paper. The adoption of a Waterfall-like methodology by the US Department of Defense in 1985 (DOD Standard 2167) is often blamed for popularizing a rigid version of Waterfall.

However, neither Bennington nor Royce used the term Waterfall in their papers, nor did they advocate a rigid process, and the same can be said for the DOD.

Royce's paper actually presented a nuanced view. He endorsed a basic model with iterative relationships between development phases. Furthermore, Royce proposed five enhancements to this basic model, one of which was continuous customer involvement - a key aspect that Agile methodologies are known for promoting.

Already in the early 1980s, anecdotal evidence began to emerge about sales practices dismissing the outdated waterfall model as something no organization should ever use. This was according to Professor David Dischave, who, despite having spent 20 years in IT application development across five major corporations, had never heard of such a model before.

Misconceptions of Waterfall

1. The frozen waterfall

Myth: each phase must be completed to 100% and its results frozen before moving to the next one.

Reality: iterative features were part of the model from its inception, as shown in Royce's original diagrams, portraying an iterative relationship between development phases.

2. No feedback from users

Myth: end-user involvement is ignored outside of requirements specification.

Reality: the Waterfall model does not exclude customer involvement after the requirements phase. In fact, the model, as originally described by Royce, includes provisions for iteration and continuous customer input, and advocates the introduction of a prototyping stage.

3. Unrealistic deadlines

Myth: waterfall means setting impossible deadlines, that are decided before really knowing what the project is about.

Reality: all three main sources indicate that there will be changes needed even after a software program goes into operations. All three state that there is significant unpredictability in developing software. Benington, in particular, reflects on lessons learned and advocates an iterative approach, estimating a potential reduction of overall time by 50%.

4. Requirements becoming outdated

Myth: too much time passes between the collection of requirements and the receipt of feedback from end users, often resulting in requirements that are no longer relevant at the time of delivery.

Reality: this is an issue of scope, rather than methodology. Nothing in the Waterfall concept prevents chunking the business needs into smaller pieces, and delivering those smaller chunks rapidly as multiple, iterative efforts.

Conclusion

The rigid version of Waterfall that is commonly criticized today seems to be a misinterpretation of the original papers. This version lacks a clear origin, but it has become ubiquitous and conveniently supports the narrative of big-"A"-agile. It suggests the notion that transitioning to Agile is a monumental effort, necessitating a dramatic shift in corporate culture. And, of course, a hero.

"Living dinosaurs did not inspire the dragon idea - they died out long before people were around to observe them. But the fossil remains of extinct animals have sometimes been taken for dragon bones--and helped perpetuate old dragon stories."

Dragon stories, while fascinating and inspiring, do not provide a practical foundation for developing wildlife management practices. Similarly, organizational change should not rely on misinterpretations of the significance of the 'fossils' retrieved from an old methodology.

References

This article owes most of its content to the analysis done by David Olson in his article THE MYTH OF THE 'WATERFALL' SLDC

Further sources (also quoted in Olson's article):

• Research Paper - Production of Large Computer Programs, by Herbert D. Bennington. From a presentation at a symposium on advanced programming methods for digital computers sponsored by the Navy Mathematical Computing Advisory Panel and the Office of Naval Research in June 1956

• Research Paper: Managing the Development of Large Software Systems, by Dr. Winston W. Royce, 1970

• The waterfall – A Historical View to Organizing Software Development. By Patrik Malmquist. 5 September 2011

• Research Paper: Toxic Concepts in Systems Analysis and Design: The Systems Development Lifecycle. By Paul Ralph. May 2010

• Research Paper: A Review of Risk Management in Different Software Development Methodologies. By Hijazi, Khdour, and Alarabeyyat. May 2012

• Article: A Waterfall Systems Development Methodology … Seriously? By David Dischave. On the Global Enterprise Technology web site. 17 September 2012.

• Article: Natural History of Dragons. From the American Museum of Natural History web site.

Location: Worldwide, Virtual    Fees: Depends on event nature and scope

Service Type: Service Offered

Location: Switzerland    Fees: Depends on scope and publication.

Service Type: Service Offered