Login
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.
In today’s rapidly changing global business environment organizations must deliver higher levels of customer and business value at increasing levels of efficiency. Organizations that continue to harbor the myth of the Iron Triangle risk becoming obsolete in the marketplace – industry dinosaurs.
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.
Within the last week alone, I heard the immutable law of the “Iron Triangle” invoked on at least two occasions. Clearly, the myth of the Iron Triangle continues to survive – and perhaps even thrives in many organizations!
My objective is to provide you with the knowledge to recognize, challenge and break through the myth of the Iron Triangle – and to move forward as an agile enterprise that enables innovation and sustainable business transformation.
An expression frequently associated with the Iron Triangle is “Better, Faster, Cheaper – pick any two.” For example, under the auspices of the Iron Triangle, you can provide your customer with a
More specifically, there is a tradeoff among better, faster, cheaper – sometimes referred to as the elastic triangle. For example, if you want to provide more quality (better), then some blended tradeoff of faster and/or price is required. Or, if you want to offer a lower price point, then some blended tradeoff of better (less quality) and/or faster (more slowly) is required.
The concept of the Iron Triangle comes in a variety of flavors across industries and organizations. However, the core concept is rigid tradeoffs (hence the concept of the triangle – the most rigid structural element in construction) among three (although it could be more than three) interrelated variables.
The rigidity of the interrelated variables of the Iron Triangle is a myth. It’s a legacy concept that pre-dates today’s business practices and enabling technologies. Today, organizations can – and to be
In other
I see it every day. Organizations that break through the myth of the Iron Triangle become agile, scalable, high-performing organizations. The dinosaurs either achieve organizational renaissance via transformational business processes reengineering or are acquired, deconstructed and folded into nimbler more innovative organizations.
To break through the myth of the Iron Triangle, the concept needs to be reframed. “Better, Faster, Cheaper” is cute and intuitive – it’s the traditional way to express the concept. However, it’s too simplistic and obfuscates the underlying principles.
The underlying principles are effectiveness and efficiency. I like to refer to these as the big “E” (effectiveness) and the little “e” (efficiency). Effectiveness is about value creation – the creation of customer and business value via you and your organization’s products and services.
The big “E” (effectiveness) distills down to four basic questions: 1) Who are my customers (internal and/or external); 2) What are my products and/or services; 3) What do my customers want from my product and services (quality, customer service, functionally, etc.); and 4) What are my customers willing to pay for my products and services (based on levels of quality, customer service, functionality, etc.)?
The little “e” (efficiency) is about delivering effectiveness (at the defined service levels) in the most economical manner. Efficiency is maintaining the
Efficiency and cost reduction are not the same concept. Cost reduction is lowering the defined levels of effectiveness to reduce costs. It’s a valid strategy – if your levels of effectiveness are set at levels higher than the value recognized by your customer (i.e. your customer is not willing to pay more for the higher levels).
To break through the myth of the Iron Triangle, shift your frame of reference from a rigid (or elastic) tradeoff among the three interrelated variables (e.g. Better, Faster, Cheaper) to a frame of reference focused on optimizing the big “E” and the little “e”.
Price is a proxy for effectiveness. Cost is a proxy for efficiency. Price and cost are independent of each other.
Price is what your customers (internal and/or external) are willing to pay based on the value that you provide via your products and services. Cost is what it costs you to provide your products and services. The spread between price and cost, for the purpose of this discussion, is the business value that your organization creates via its products and services.
Herein lies the fallacy of the Iron Triangle. I maintain that an organization can improve effectiveness (improve value and therefore maintain higher price points) and simultaneously improve efficiency (provide the higher levels of effectiveness at lower costs).
Conversely, perpetuating Iron Triangle thinking leads to ineffective, inefficient organizations that become lumbering dinosaurs on their way to economic extinction. But, also, herein lies the opportunity. Organizations that “get” the concept of driving both the big “E” and little “e” simultaneously are positioned for innovation and profitable growth.
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).
In my book, Mastering Business Chaos, I differentiate complicated, complex and chaotic systems. A brief overview of the difference:
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.
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.
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.
Organizations today operate in a complicated, complex, rapidly changing chaotic business environment. Accordingly, an organization’s business processes and supporting business systems are increasingly complicated and complex and must continually adapt to rapidly changing business requirements driven by the chaotic environment.
Likewise, the spectrum of business analysis (business process analysis, business systems analysis, business requirements analysis etc.) and application software solutions takes place within and aligns to support this chaotic environment.
A critical success factor to delivering high levels of effectiveness and efficiency in a chaotic environment is agility over rigidity.
Agility is the ability to execute a quick and well-coordinated movement. I would revise and extend the definition to: The ability to rapidly recognize changes in the environment (e.g. in football - the play as it evolves on the playing field) and to execute quick and well-coordinated movements in response to the changes.
My definition of agile business analysis is the rapid identification and professional analysis of business requirements within a rapidly changing chaotic business 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 the customer and business value. In other words – delivering increasing levels of effectiveness – the big “E” (e.g. better requirements, faster requirements) and at increasing levels of efficiency – the little “e” (more economically).
Maximizing the customer and business value is not just an aspirational objective. Agile business analysis is a core objective – it comprises a spectrum of techniques and methods to maximize customer and business value – 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 enables organizations to break through the myth of the Iron Triangle by replacing the legacy notion of the Iron Triangle with the 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 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
It's a very complex, globally competitive, rapidly changing business environment. Ask yourself some critical questions. Are the business processes and supporting applications in your organization really keeping pace with ever increasing demands for organizational effectiveness and operational efficiency?
Do your team and your organization have the critical thinking skills and analysis techniques to rapidly identify, analyze and articulate essential business requirements? Are you able to rapidly define and specify your business requirements at the level of detail of functional requirements?
If you can, what are the benefits? If you can’t, what are the risks?
Successful business analysis requires business knowledge, adept judgment and seasoned experience. Inteq’s elite business analysis training programs and professional consulting services enable you, your team and you organization to achieve high-impact high-value results quickly.
