360° expert in Project Management with wide experience from different perspectives as a Portfolio Manager and setting up PMOs for individual projects and for whole organizations.
Available For: Advising, Authoring, Consulting, Influencing, Speaking
Travels From: Switzerland
Speaking Topics: Project Management, Digital Transformation
Fabio Turel | Points |
---|---|
Academic | 15 |
Author | 112 |
Influencer | 17 |
Speaker | 58 |
Entrepreneur | 60 |
Total | 262 |
Points based upon Thinkers360 patent-pending algorithm.
Credential ID FHRU56ZKT9G8
Tags: Agile, Digital Disruption, Project Management
Tags: Agile, Project Management, Risk Management
Tags: Agile, Project Management, Risk Management
Tags: Digital Transformation, Mobility, Project Management
Tags: Agile, Project Management, Risk Management
Tags: Agile, Leadership, Project Management
Tags: Agile, Project Management, Risk Management
Tags: Agile, Change Management, Project Management
Tags: Agile, Leadership, Project Management
Tags: Culture, Project Management, Risk Management
Tags: Agile, Project Management, Risk Management
Tags: Agile, Project Management, Risk Management
Tags: Agile, Project Management, Risk Management
Tags: COVID19, Project Management, Risk Management
Tags: IT Strategy, Project Management, Risk Management
Tags: Digital Transformation, Project Management, Risk Management
Tags: COVID19, Project Management, Risk Management
Tags: IT Strategy, Project Management, Risk Management
Tags: Agile, Project Management, Risk Management
Tags: IT Strategy, Project Management, Risk Management
Tags: Business Continuity, Project Management, Risk Management
Tags: Business Continuity, Project Management, Risk Management
Tags: IT Strategy, Project Management, Risk Management
Tags: IT Strategy, Project Management, Risk Management
Tags: Culture, Project Management, Risk Management
Tags: Agile, Project Management, Risk Management
Tags: Project Management, Risk Management
Tags: Culture, Project Management, Risk Management
Tags: Agile, Culture, Project Management
Tags: Agile, IT Strategy, Project Management
Tags: Agile, IT Strategy, Project Management
Tags: Agile, IT Strategy, Project Management
Tags: Business Strategy, Culture, Project Management
Tags: COVID19, Project Management, Risk Management
Tags: Agile, IT Strategy, Project Management
Tags: Culture, Leadership, Project Management
Tags: IT Strategy, Project Management, Smart Cities
Tags: Culture, IT Strategy, Project Management
Tags: Agile, Project Management, Risk Management
Tags: Agile, Project Management, Risk Management
Tags: IT Strategy, Metaverse, Project Management
Tags: Agile, Digital Transformation, Project Management
Tags: Agile, Project Management, Risk Management
Tags: Digital Transformation, Project Management, Risk Management
Tags: Agile, Digital Transformation, Project Management
Tags: Agile, Digital Transformation, Project Management
Tags: Metaverse, Project Management, Risk Management
Tags: Metaverse, Project Management, Risk Management
Tags: Agile, Project Management, Risk Management
Tags: Agile, Digital Transformation, Project Management
Tags: Culture, Project Management, Risk Management
Tags: Culture, Digital Transformation, Risk Management
Tags: Project Management
Tags: Project Management
Tags: Culture
Tags: Agile, IT Strategy, Project Management
Tags: Agile, Digital Transformation, Project Management
Tags: Agile, Digital Transformation, Project Management
Tags: Agile, IT Strategy, Project Management
Tags: Agile, Culture, Risk Management
Tags: Innovation, Project Management, Risk Management
Tags: Digital Transformation, Metaverse, Project Management
Tags: Metaverse, Project Management, Risk Management
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.
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.
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.
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.
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.
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.
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%.
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.
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.
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.
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.
Tags: Agile, Project Management, IT Strategy
The road to agile transformation is more treacherous than many anticipate. A recent study highlights a sobering reality: nearly half of all attempts to implement agile practices across businesses fail, with two-thirds of these failures being irrevocable.
Despite these alarming statistics, every example of successful implementation of agile in IT could be a model for other business areas. It's not just about adopting new processes; it's about nurturing a mindset geared towards delivering consistent value and being agile enough to change course when needed.
It’s a fascinating concept, really, because what’s at the heart of agile isn’t just a set of practices or tools — it’s a mindset focused on delivering consistent value and being ready to pivot when you realize your current path isn’t hitting the mark.
Here’s the kicker: it’s less about the agile ceremonies and rituals we’ve come to know, and more about a few critical elements
This is all about understanding what you’re creating and how it can be improved and expanded, piece by piece, in manageable, short bursts. Think of it like building a puzzle — one piece at a time, but with a clear picture of the end goal.
Every project needs a captain of the ship, someone who’s not just keeping an eye on things but is actively steering the course. This person shoulders the responsibility for the project’s outcome. They’re the go-to person, the one making the tough calls.
The title — be it product owner, sponsor, business owner, principal, or any other — doesn’t matter as much as the authority that comes with it. This individual needs the power to make decisions, right then and there, without having to wait for another meeting with the ‘real’ decision-makers.
These three factors are the pillars of what I call small-”a”-agile: an adjective, not a noun; a set of capabilities to be cultivated, not a one-size-fits-all recipe to achieve them.
The second point about ownership and responsibility, in particular, resonates with the traditional role of a project manager. It’s about translating the big picture — the investment logic — into actionable, value-driven steps. And the other way around: help the individual teams see their contribution to the big picture (the “project product”), while staying true to the core mission of their function (their “team product”).
Incremental delivery is the name of the game, where each step brings tangible value.
In short, agility in business, much like in IT, is about adapting, delivering, and evolving effectively. It’s a journey of continuous improvement, not just in what we deliver but in how we think about and approach our work.
Tags: Agile, Project Management, IT Strategy
Location: Worldwide, Virtual Date Available: January 26th, 2024 Fees: Depends on event nature and scope
Submission Date: November 26th, 2023 Service Type: Service Offered
Location: Switzerland Date Available: November 26th, 2023 Fees: Depends on scope and publication.
Submission Date: November 26th, 2023 Service Type: Service Offered