Agile Business Analysis: Breaking the Myth of The Iron Triangle, Part 2

In Part I of the Agile Business Analysis - Breaking through the Myth of the Iron Triangle, I presented my position that the rigidity of the interrelated variables of the so-called Iron Triangle (e.g. Better, Faster, Cheaper) is a myth.  By reframing the concept into effectiveness (creating customer and business value) and efficiency (creating value in the most economical manner) an organization can break through the myth.

The Iron Triangle is a legacy concept that pre-dates today’s business practices and enabling technologies.  The concept stifles business innovation, creates artificial barriers to sustainable business transformation and is a key contributor to suboptimal performance in many business analysis and IT projects.

Today, organizations can – and to be competitive must, achieve higher levels of quality with faster response times at increased levels of efficiency.  Organizations that continue to harbor the myth of the Iron Triangle risk becoming obsolete in the market place – industry dinosaurs.

Accordingly, I advocate replacing the mythical Iron Triangle with the Inteq Agile/Framework™

The Iron Triangle of Information Technology Projects

The same legacy concept of the Iron Triangle applies to information technology (IT) projects – particularly with application software related projects – analysis, design and development.

The Iron Triangle of application software related projects is typically expressed as the dimensions of time, scope and budget.  The concept of rigidity is that it’s a zero-sum game – an improvement in any one of the three dimensions is at the expense of some combination of the other two dimensions.

The Iron Triangle of application software related projects is a myth – and is a legacy concept as well.   Time, scope and budget are far too simple of a model and obfuscates the numerous interrelated variables that are in-play in the analysis, design and development of enterprise class software solutions.

The good news is that it’s not a zero-sum game.  Recognizing the variables and applying agile techniques and methods to the variables enables increased levels of effectiveness (customer and business value) at increased levels of efficiency (the economics of delivery customer and business value).

Complicated, Complex and Chaotic

In my book, Mastering Business Chaos, I differentiate complicated, complex and chaotic systems.  A brief overview of the difference:

• Complicated: Complicated systems have many interrelated moving parts – however, the interrelated parts move mechanically.  A Swiss watch is complicated system.  There are many moving parts that comprise the watch mechanism that move mechanically.

• Complexity:  A Swiss watch is complicated, but not complex.  In complex systems, the interrelated moving parts interact with each other in non-mechanical ways.  If you have ever played (or watched) an interactive on-line multiplayer game you have experienced complexity. The games are complicated – many players, each player has a range of skills (and level for each skill); a range of tools to apply based on each player’s rank and achievements. The games are complex – each of the players apply their skills and tools based on individual and team strategies and tactics to achieve various objectives – sometimes in alliance and sometimes in competition with other teams and individuals.  The alliances are not static and frequently change during the game.

• Chaotic: The games are complicated and complex, but not chaotic.  Once the game starts, the underlying map and rules of engagement are set for the duration of the game.  Chaotic systems have changing external variables that influence how the moving parts interact in non-mechanical ways. An organization is a chaotic system.  There are many interrelated moving parts that comprise an organization that interact in non-mechanical ways and the interaction is continually influenced by external variables such as economic conditions, regulations, competition, etc.

My definition of agile business analysis is the rapid recognition and analysis of business requirements within a chaotic project environment to get the right requirements "right" – by using the right techniques, to deliver the right level of detail and precision, to the right people at the right time to maximize customer and business value.

Agile business analysis has the overarching objective of maximizing customer and business value.  In other words – delivering increasing levels of effectiveness (e.g. better requirements, faster requirements) and at increasing levels of efficiency (more economically).  However, it’s not just an aspirational objective.  Agile business analysis comprises a spectrum of techniques and methods to achieve the objective – breaking through the myth of the Iron Triangle.

To break through the myth, let’s start by challenging the notion that the value drivers (also known as the dimensions of effectiveness) of a product or deliverable are “better”, “faster” and “cheaper”.  These terms are ambiguous – what defines “better” and “faster”?  Does “cheaper” imply price or cost?

The reality is that there are many value drivers that comprise effectiveness such as quality of output (better in terms of lower defects, better conformance with specifications, etc.), functionality “fit” for use of the output (better fit with customer needs and expectations), timeliness (meeting delivery intervals – which could be fast intervals, but not necessary), usability, extensibility, re-use, etc.

The value drivers that apply to the development of the products / deliverables of business analysis within any project need to be identified and prioritized and the appropriate standard or level of service needs to be defined for each driver.   It’s key to recognize that the drivers, priority among the drivers, and standards / service levels of each driver change frequently.

Second, let’s challenge the traditional notion of the IT Iron Triangle: time, scope and budget.  These are not value drivers – these are constraints.  In addition to time, scope and budget, there are many other potential constraints such as resource talent availability, subject matter expertise and accessibility, regulatory compliance, technology, etc.

The constraints that apply to the development of the business analysis products / deliverables within a project need to be identified and prioritized, and the appropriate standard or level needs to be defined for each constraint.   It’s key to recognize that the constraints, like the value drivers, are not static – the priority among the constraints, and the standards / levels of each constraint change frequently.

Third, there are a spectrum of business analysis techniques and methods that can be applied to developing business analysis products / deliverables to maximize customer and business value of the product / deliverables based on the value drivers and within the constraints of the project.  Examples include activity diagrams, user stories, scenario analysis, backlog analysis, risk analysis, sprints, etc.

The business analysis techniques and methods applicable to the products / deliverables of a project need to be identified, prioritized and applied as appropriate.  The key is to understand that, like the value drives and the constraints, the applicable techniques and methods are not static – the applicable techniques and methods and the application of the techniques and methods change frequently.

Agile Business Analysis - Creating a Fine Gem

Agile business analysis enables organizations to break through the myth of the Iron Triangle by replacing the legacy notion of the Iron Triangle with the Inteq Agile/Framework™.  The application of the Agile/Framework™ enables business analysts to rapidly recognize (even anticipate the changes in the variables in the project and business environment.

The application of the Inteq Agile/Framework™ enables business analysis to execute quick and well-coordinated movements in the allocation of project resource and the application of analysis techniques and methods in response to the changes to get the right requirements "right" – by using the right techniques to deliver the right level of detail and precision, to the right people at the right time to maximize customer and business value.

Perhaps our role as professional business analysts are similar to expert diamond cutters.  We identify and grade the rough diamonds that are requirements – and then quickly, expertly and precisely analyze, cut and polish the requirements into the resulting high-value fine gems of deliverables to our customers.

Subscribe to my blog | Visit our Knowledge Hub

Visit my YouTube channel | Connect with me on LinkedIn

Check out our Business Analysis Training Courses and Consulting Services